Hi, I'm not sure if this idea came up before, but as far as I can see there is no bug open about it and last time I checked dpkg didn't support the following idea. In autopkgtest [1], I added support in the testing control file to explicitly mention unsupported architectures. This means that instead of listing all supported architectures, one can say something like: Architecture: !s390x which means the same as '`any` but not on s390x', just like in (Build-)Depends. Maybe you consider this a stupid idea, but from where I stand this looks like a nice feature. Paul [1] https://salsa.debian.org/ci-team/autopkgtest/-/blob/master/doc/README.package-tests.rst
Hi Paul, I've seen this idea frequently, but do not remember any concrete instance at this time. I note that the Architecture field in the binary package serves subtly different purpose. Effectively, there are three distinct purposes that we currently accomplish with this field: * Determine whether a binary package is all/indep or any/arch. * Determine on which architectures a binary package is to be emitted. * Skip building packages when unsupported. You are mainly targeting the last purpose here. If your package has many binary packages, repeating this information quickly becomes tedious. The alternatives suggested thus far are: * Build-Depends: architecture-is-64bit * Build-Depends: unsupported-architecture [s390x] I agree that this is not super obvious, but it technically works right now in a practical way. Helmut
Hi! My reply at <https://lists.debian.org/debian-devel/2022/09/msg00148.html>, covers some of this, and links to various related requests for this, with rationale on the general problem: https://bugs.debian.org/797347 dpkg-gencontrol: option to exclude specific architectures https://bugs.debian.org/807264 dpkg: Please allow negative Architecture lists in debian/control https://bugs.debian.org/962848 dpkg-architecture: please add aliases for 32-bit 64-bit bad-endian https://bugs.debian.org/807263 dpkg-architecture: Please provide parameter to list all known wildcards In some of those I might have mentioned that this is kind of already supported in the Architecture field, but that was meant to refer to the build dependencies syntax, where in Debian we do not currently allow it but the code in dpkg supports stuff like combining negative and positive arch lists (although its behavior is not currently well defined or documented). Which ties into whether supporting this at all would really imply making this the most general possible, and not just allowing to specify negated arches, I guess one would potentially want to specify stuff like: Architecture: linux-any !arch:32-bits !s390x and whether the order is relevant, and how, etc. But then see the thread above, related to porting, and status tracking. While I'd love to have better (read native/builtin) support for say endianness and bitness restrictions in either the build dependencies and the Architecture field, as I think I've mentioned elsewhere the biggest problem is that this would require to hunt and adapt everything that parses any of these, and make them understand the new arch properties supposedly from some dpkg table, which would affect satisfiability tests for example that might otherwise work in the abstract based only on arch names. While the current dependency based solution feels a bit bolted on, it has the nice properties that it is self contained within an archive, it's explicit instead of implicit, and works right now. In any case, I'm open to pondering and/or trying to get a design rolling for a potential builtin solutions for these category of problems, with the assumption that even if dpkg grows support for any of this, I don't expect it would be usable for years, until all other pieces have also grown support for it. Although as mentioned in the initially referenced thread, it seems to me supporting this might also be counterproductive for porting efforts, or perhaps a workaround for better build status tracking (which could also need some different support added to dpkg)? Thanks, Guillem
Hi, Seems like I didn't search well. Those match my idea. I agree. I was aware of the architecture-is-64bit, but not (until recently) of unsupported-architecture. Maybe the biggest challenge is to share the idea. My annoyance was mostly with people writing out a list of architectures to exclude one (and forgetting to update it later when archs are added or the package gets fixed). I agree with you they shouldn't do that, a FTBFS is fine. I *guess* maintainers either don't like those FTBFS for $reasons, or the build actually doesn't fail but misbuilds. Having a declarative way in d/control to prevent that is nice, "hacking" up something in d/rules feels less nice (and for me would be more work). So, "BD: unsupported-architecute [!arch]" it is; I'll promote it more. Paul
patches for https://www.debian.org/doc/manuals/developers-reference/developers-reference.en.html#best-practices-for-debian-control most welcome! :) though there is nothing about architectures there so far, so maybe https://www.debian.org/doc/manuals/developers-reference/developers-reference.en.html#being-kind-to-porters would be better.
Hi Paul, saw it and smiled :) also saw that Helmut has suggestions to improve it, so I'm not merging this right away, but soon. Thanks!