Control: merge 797347 -1 On Sun, 2015-12-06 at 21:49:52 +0100, Axel Beckert wrote: > Package: dpkg > Version: 1.18.3 > Severity: wishlist
> it's rather tedious to find the correct "Architecture:" value for a > binary package -- and also to keep it uptodate with the growing list of > architecture -- if only one or two architectures need to be excluded. > > It would be very convenient and also future-proof if I could specify > e.g. "!arm64 !any-arm" in the "Architecture:" field in a binary > package stanza in debian/control, in line with the negative architecture > lists that can used for build-dependencies. This was filed some time ago. There's some rationale on the other bug report, but after some more consideration I'm not sure allowing this would be a good idea. The Architecture field percolates into many places, which means lots of things would need to be hunted down and updated. It gets into .dsc and .changes Architecture fields. Also in the arch key/value in the Package-List field in the .dsc. Not to mention anything that parses the Architecture field directly from debian/control. Can you present a case where using a negative specification would be more correct than a positive one? In general I think the main cases to consider are, a package supports a specific set of kernels, in which case positive kernel wildcard might seem best. Then there's the packages that either are specific to a very tiny set of architectures, like ia64-specific tools or firmware (positive here too). And then packages which might fail to build on a wider set of architectures, due to things like endianness, alignment, etc. In which case I think the correct thing to do is to mark the package as ‘any’ and let the porters port it. The difference between the Architecture field and the arch restrictions in dependencies is that the latter accept alternatives, so you might want to say things like: libalsa-dev [linux-any] | liboss-dev [!linux-any] for example, which does not apply in binary packages. Thanks, Guillem
