Hi!
To avoid hardcoding arch lists in theory you could use one of the virtual
packages from architecture-properties in build dependencies, such as:
architecture-is-64-bit | foo-for-32-bit,
architecture-is-little-endian | bar-for-big-endian,
But this is rather hackish, and in addition it should not work on Debian
buildds where (AFAIR) only the first alternative is ever considered.
For run-time dependencies you could inject the arch list via a substvar,
by fetching the values from something like:
dpkg-architecture --match-bits 64 --list-known
dpkg-architecture --match-endian little --list-known
I think it would be nice, alongside bitness, but not by using the same
namespaces as architectures. This same thing was requested in #962848,
(and I thought I replied, but perhaps only on IRC or private mail or
something? Or maybe in conversations with Niels, that ended up with the
current architecture-properties approach). I also now just found
references to something like this in #630342.
Reusing the arch namespace means that declaring these dependencies will
silently not get satisfied until all resolvers get updated, which I
think would be rather bad. To me this calls for a breaking change, by
adding some new syntax that hopefully separates this notation from
existing arch names. I've just not been sure what to use here, and I
shudder at this type of "update all resolvers" kind of change. And the
existing approach while a bit cumbersome (and TBH a workaround for a
limitation in the base tools), just works for most stuff right now (but
not your first case) and requires no ecosystem-wide changes to the
syntax.
If our arch tuples were a bit more rich, then we could probably match
on those attributes, but then there are other attributes that we might
eventually also want to match on that would not be present anyway.
The first thing that comes to mind might be something like:
arch:32-bit
arch:64-bit
arch:little-endian
arch:big-endian
or perhaps:
arch:bits:32
arch:bits:64
arch:endian:little
arch:endian:big
or variations on that, perhaps arch:<attr>=<value>, dunno. Where this
could make it possible to extend to other arch attributes (although I'm
not sure any other attributes might be very useful), such as for
example:
arch:char:signed
arch:char:unsigned
arch:exec:elf
arch:exec:mach-o
…
In any case there might be other/better ways to represent this. And the
prefix at least feels a bit redundant when used in an Architecture field.
I guess another problem is that resolvers would need (ideally) to get
the information about these attributes from the dpkg arch tables, but
that might be annoying to deploy or rely on. Thus this might need input
from at least the major resolver implementations.
Probably, and I actually had implemented this some time ago, but was not
sure whether it was worth it, so ended up not merging it:
https://git.hadrons.org/cgit/debian/dpkg/dpkg.git/commit/?h=next/substvars-arch&id=87b68cee48a3ce66cd93c145d78491c67e9ed8aa
But if there's demand, I'm happy to merge it, after I've cleaned this
a bit.
Thanks,
Guillem