Nikolaus Rath wrote... > Just fix it in "bar", and don't bother worrying about the right > severity?
If it was that simple ... The maintainers of "bar" haven't reacted to
the bug report for a few months although it contains a clear statement
the current state breaks the build of other packages. And in general I
include patches into my bug reports, but the "bar" package is rather
big, some 400 kLOC. I have a vague idea of what precisely is supposed
to happen. Also I already spent some time to find the change. The last
hours I've been playing with gcov to find differing code paths taken,
so far no avail.
Still, I might get this sorted out. However, this incident raised a
second, more generic question: Is this an acceptable state? If John
wants to rebuild packages like "foo", he cannot simply use his
preferred architecture. The build may fail, then he has to start
trying other ones until success. I don't consider this a satisfying
situation. On the other hand I can understand Debian maintainers
wern't very happy to learn a bug in the toolchain of a doorstopper
architecture causes FTBFS there for one of their packages, which might
even result in a removal from testing.
So I was looking whether there is a consensus about this. If not, I
wouldn't mind if this ends in a guideline (seems a bit to much in
detail for Debian policy) about packages that solely build arch:all
binary packages. Like: They must be buildable at least on certain
architectures, I called them "mostly used architectures" in my first
mail. I would strongly suggest that list should not solely consist of
amd64.
Christoph
signature.asc
Description: Digital signature
