Hi! On Thu, 2024-10-17 at 10:23:41 +0200, Helmut Grohne wrote: > On Thu, Oct 17, 2024 at 09:35:17AM +0200, Paul Gevers wrote: > > 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. > > I've seen this idea frequently, but do not remember any concrete > instance at this time.
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. > > 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. > > 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. 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
