On Tue, 2016-03-08 at 08:27:32 +0100, Axel Beckert wrote: > Guillem Jover wrote: > > Can you present a case where using a negative specification would be > > more correct than a positive one? > > "More correct" maybe not (not sure what "more correct" means as > "correct" is boolean for me), but surely way easier to maintain since > I wouldn't have to follow all new architectures which pop up > occassionally: > > There was a time where gnudatalanguage didn't build on exactly one > architecture (arm64): See https://bugs.debian.org/803552 and > https://anonscm.debian.org/cgit/debian-astro/packages/gnudatalanguage.git/commit/?id=638bc9c3be31a4e5bd747f6c0f985da1afbc26ba > > The full architecture list reads: > > Architecture: any-alpha any-amd64 any-armeb any-arm any-avr32 any-hppa > any-i386 any-ia64 any-m32r any-m68k any-mips any-mips64 any-mips64el > any-mipsel any-or1k any-powerpc any-powerpcel any-ppc64 any-ppc64el > any-s390 any-s390x any-sh3 any-sh3eb any-sh4 any-sh4eb any-sparc > any-sparc64 mipsn32 mipsn32el powerpcspe x32 > > I had to write small script to get it done properly and found that > line/commit rather tedious. And if the bug wouldn't have been fixed > properly soon afterwards, I'd have had to keep that field uptodate or > at least check it everytime a new architectures pops up, e.g. on > Debian Ports.
This falls into one of the cases I mentioned in my previous mail. Here I think to correct course of action would have been to request the removal of the offending binaries for the broken arch. That makes that FTBFS non-serious as it's not a regression (anymore). And the buildds will be able to build it with a simple retry (automatic or manual), and no new upload is required. If the problem would have been, say, a misbuild instead of a FTBFS, I'd probably have opted for adding instead a '$(error )' call in debian/rules on arm64, which is a hack, but a temporary one in any case, and certainly more manegable. There's a very relevant thread on debian-devel started by Steve Chamberlain, precisely about the underlying issue caused by using exclusions instead of inclusions in Architecture fields which I think also is spot on. Thanks, Guillem
