On 6/5/05, Tollef Fog Heen <[EMAIL PROTECTED]> wrote: > * "Michael K. Edwards" > > | So either Debian collectively is > | willing to labor to maintain a high standard of portability and > | stability, or we need to focus on a few arches and ignore > | bugs-in-principle that don't happen to break on those systems. > > At the same time, if we're releasing i386, powerpc and amd64 we have a > fair bit of spread: We have both little- and big-endian, we have 32 > bit and 64 bit and we have signed and unsigned char and we have > linuxthreads and pure NPTL threading libraries. > > This doesn't uncover all possible build and runtime problems, but it's > a good start to having portable code.
In 1990, this was a good start (substituting vendor variants of thread libraries for linux variants). In 2005, a good start is to have a variety of processor alignment constraints, a variety of OCaml and gcj native-code back ends (and absences thereof), a variety of space/speed trade-offs in the gcc -O2 defaults, and a variety of kernel micro-versions. Granted that that's a higher quality standard than could seriously have been proposed in 1990, but if you ever paid the FSF $5K for a coherent GNU tools build (as I did back then), you know how much the state of the art has improved. When I first packaged an OCaml library with a native-code component, I struggled with build issues on unfamiliar Linux ports. That's a _good_ thing. It meant that I had to learn the difference between optimized and optimizing OCaml compilers, and to fix broken upstream build scripts that didn't make the distinction correctly. Next year, when open-source MMIX cores have the best bang-for-the-buck in embedded space :-), we'll be glad that Debian's 11 architectures cover quite a bit of autoconf parameter space. Cheers, - Michael