Hello,
it is the nature of an arch:all binary package it can be installed on
any architecture regardless on which architecture it has been build.
Given this I deduced I'm at liberty on which architecture I'd want to
rebuild such a package, but I saw disagreement. So I'm asking for
clarification:
Given a simple source package "src:foo" that produces one arch:all
binary package "foo". The build needs the help of package "bar" which
happens to be arch:any, so technically speaking the build process isn't
identical while the result should be. (If you need an example, the
thousands of pure Perl library packages are of that kind.)
Now "bar" behaves different on different architectures, very likely
due to a bug, eventually resulting in a build failure on some while it
passes on other. More precisely, "bar" hasn't changed in years, the
problems began with a recent new upstream version of "foo". The
maintainer did the upload using a passing arch and probably never even
noticed.
Basically, there are two ways to judge this situation:
a) While "bar"'s behaviour certainly is questionable, this does not
affect "foo" as long as it builds on at least one architecture (or a
subset of the mostly used ones).
b) This is a serious issue as John D. Rebuilder should be free to choose
on which architecture to build "src:foo".
Personally, I tend to b) since
* there is no sane way for the maintainer to tell the world which
architecture should be used to rebuild this package. The .buildinfo
file will solve this, still
* it is certainly rather unfriendly to expect John to have a box for
that particular architecture just to be able to do the rebuilding.
On the other hand, option b) implies "src:foo" must build on *all*
architectures, and obviously such rebuild tests do not happen: Else the
build error I stumbled upon would have already been reported, and
hopefully fixed as well. In other words: This is a real story, I'm not
making it up. Also, the failing architecture isn't even an excotic one.
In my opinion "src:foo" should see a "serious" bug report FTFBS,
although it's just a victim of "bar". What about "bar"?
Other suggestions?
Christoph
Attachment:
signature.asc
Description: Digital signature