XPost: linux.debian.bugs.dist
From:
guillem@debian.org
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
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)