STeve Andre' <[EMAIL PROTECTED]> wrote:
> This brings up the issue of wether a porter needs to have access
> to all the arches supported in order to submit something. That
> it fails on the alpha isn't good, but should that preclue its inclusion?
> if it were in the ports tree and someone with an alpha that wanted
> to use it found it didn't work, they could work on it as well.
I think we need to distinguish different kinds of architecture-
dependence.
(1) Some applications are inherently only applicable to select
architectures.
E.g.: grub
(2) Some applications need the addition of specific support for
each architecture to run on.
E.g.: mozilla-* with its assembly language stubs for callbacks
(3) And then there are applications that don't have any architecture-
specific parts and should run everywhere, but fail to do so
because of some implicit assumptions that ignore the basic
portability concerns of data type sizes, endianness, and natural
alignment. Essentially, these applications are buggy.
Class (3) usually doesn't fail on individual architectures, they
fail on ranges of architectures that share the same characteristics.
Sometimes the failure is benign on those archs where it doesn't
show up (alignment), sometimes you're just getting away with it by
accident (mixed 64/32-bit accesses on little-endian archs) and the
bug is just waiting to bite you in your posterior later on.
> This is a useful port right now. It could stand to be improved by
> getting it to work on other arches , but should (i386, amd64) be
> deprived of it?
What I'm against here is reflexively slapping on an ONLY_FOR_ARCHS/
NOT_FOR_ARCHS. The problem needs to be examined, fixes contemplated,
and an informed decision made, weighing such factors as our ability
to produce a fix, the value of the port, and its position in the
dependency tree. (I hope that doesn't sound too managerial.)
--
Christian "naddy" Weisgerber [EMAIL PROTECTED]
