On Mon, 21 Mar 2005 15:02:39 +0100, Wouter Verhelst <[EMAIL PROTECTED]> wrote: [snip] > Uh. Most porting bugs that require attention fall in one of the > following areas: > * Toolchain problems (Internal Compiler Errors, mostly) > * Mistakes made by the packager. Quite easy to fix, usually. > * Incorrect assumptions in the source code. These are becoming > increasingly rare these days, IME.
The challenging bugs tend to involve all three factors. For instance, I was just looking at a FTBFS for lineak-xosdplugin on Ubuntu/ia64. It turned out that there was: - a historical toolchain problem that XFree86 kludged around with a static Xinerama_pic library - an incorrect assumption upstream (adding -lXinerama_pic both to the xosd library build and to the xosd-config output) - out-of-date packaging; for XFree86 4.3 and Xorg, the package should build-depend on libxinerama-dev and build-conflict (if there were such a thing) with xlibs-static-pic Note that the xosd build itself did not break; but packages that use it FTBFS when there's a distinct Xinerama_pic, and may be subtlely broken on platforms where -lXinerama gets linked statically into libxosd.so.2 but is still included in the xosd-config output. Having a big matrix of platforms vs. packages, on which packagers are expected to take problems seriously, is really good for software quality. It's easy to dismiss FTBFS on minority platforms as "buggy gcc back end", and that may have been the most common cause during the gcc 3.[0-2] interval. But there are plenty of other root causes, especially outside C/C++ space, and ignoring them can cause serious build rot over time. For instance, on some platforms, the Ocaml compiler (itself an Ocaml bytecode in its basic incarnation) also comes in "native" (compiler binaries that produce bytecode) and/or "optimizing" (produces stubs and shared objects instead) varieties. Some library upstreams confuse the two when deciding whether to build the optimized form, leading to FTBFS on hppa. Debian packagers are expected to fix that, which makes a big difference to portability onto new platforms. It's a lot easier to focus on the arches that upstream cares about, or to define a set of core packages and deprioritize FTBFS on the rest (even if the problem is actually in the core package). But that doesn't accomplish what I look to Debian for. Debian's the single most effective caretaker of the software commons largely because it doesn't settle for build rot, and pushes that expectation to the outer limit of feasibility with each release cycle. Cheers, - Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
