* Kurt Roeckx <k...@roeckx.be> [110831 00:01]:
> On Mon, Aug 29, 2011 at 01:06:15PM +0200, Lucas Nussbaum wrote:
> I think to have a useful discussion we need to start with the
> different kind of failures we can actually see that are arch
> dependend. Some of those shows up on only 1 or 2 arches, some
> show up on all but 1 or 2 arches:
> 1) The source package just bails out because it never heard
> of that port, or needs to know that it's 32 or 64 bit, or
> that it's needs assembler, or it's just missing $arch in
> the control file somewhere, or has a broken configure script
> that checks the wrong thing, or whatever.
> 2) It has some undefined behaviour, it works on some arches
> and fails on others. But it's not a problem with the port
> or toolchain. But porters might know that those show up
> from time to time.
There's nothing in "being porter" that makes one better at
handling those, that's just general "know what you do", which of
course will usually be more often found with porters than with the
random DD hardly knowing the difference between compiler and
interpreter.
> 3) Packages that assume that some implementation defined behaviour
> is the same on all arches like that a char is signed on some
> ports and unsigned on others, that a size_t and long are the
> same size, that a pointer fits in an integer, ... Some of
> those cause a compiler error or warning only on a few arches.
> 4) Packages that have arch specific code that does the wrong
> thing.
4b) Packages that have some arch-specific code and some fallback
code for unknown architectues, with the fallback code utterly
broken.
> 5) Packages where the author only uses Linux and are just not
> written with portability in mind. This might include things
> like using Linux specific APIs and header files, using various
> extention without checking that they're available, not working
> on big endian machines, ...
"only uses Linux" and "not working on big endian machines" look
quite unrelated.
> 6) Packages that have timing problems that only show up on some
> arches or buildds because they're faster or slower.
Or because the buildd use a different filesystem, or some slightly
different kernel, or or or ...
Bernhard R. Link
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/20110831092202.gb12...@pcpool00.mathematik.uni-freiburg.de
