Re: The 98% and N<=2 criteria
On Mon, 21 Mar 2005 15:02:39 +0100, Wouter Verhelst <wouter@debian.org> 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
Reply to: