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