Hi, On 10/11/26 07:38, Guillem Jover wrote:
I have a package where my build dependencies change based on host endianness, and I also need to generate dependencies in the binaries based on endianness.
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.
Indeed, that's one of the reasons I don't like architecture-properties. :>
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
Gladly, I don't need that at this time, but this generates a massive list.
Presumably I could also substitute
dpkg-architecture --match-endian big --list-known \
| sed -e 's/.*-/any-/' -e '/-/!s/^/any-/' \
| sort \
| uniq
to get it down a bit (but that also feels like a hack).
BTW, combining "--is" and "--list-known" doesn't work for me, is that
supposed to work?
$ dpkg-architecture --is any-amd64 --list-known [...] solaris-sparc64 mint-m68k
1. Does it make sense to add arch restrictions [bigendian] and [littleendian] so I don't have to list the known big and little endian architectures?
I think it would be nice, alongside bitness, but not by using the same namespaces as architectures.
To me, it behaves like an architecture wildcard, and inventing a new syntax would require additional resolver rules on how to do intersections and unions, when we already have those for the existing wildcards.
Maybe we could make this more clear with [any-bigendian] or [any-64bit].
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.
We could list the wildcard along the known architectures in Debian for whatever transition period there is. Porters will probably be the first to update their resolvers then.
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.
We're a bit limited in punctuation if it needs to work inside a dependency spec, otherwise something like
any(endian=little)
might work, but round, square and angle brackets already have another
meaning. Curly braces might work, but this feels wrong, and is also a
lot more work to add to resolvers than just a bunch of new wildcards.
2. Does it make sense to add a predefined substvar "Endian" that gives the same value as "dpkg-architecture -qDEB_HOST_ARCH_ENDIAN"?
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.
Well, for certain values of "demand" (one package). Right now, I get by with
echo "Endian!=`dpkg-architecture -qDEB_HOST_ARCH_ENDIAN`" \
| tee -a debian/nextpnr-ice40.substvars \
| tee -a debian/nextpnr-ice40-qt.substvars \
| tee -a debian/nextpnr-ecp5.substvars \
| tee -a debian/nextpnr-ecp5-qt.substvars \
| tee -a debian/nextpnr-himbaechel-gowin.substvars \
| tee -a debian/nextpnr-himbaechel-gowin-qt.substvars \
| tee -a debian/nextpnr-himbaechel-gatemate.substvars \
| tee -a debian/nextpnr-himbaechel-gatemate-qt.substvars \
| tee -a debian/nextpnr-himbaechel-xilinx.substvars \
| tee -a debian/nextpnr-himbaechel-xilinx-qt.substvars
and I would need to keep some compatibility code around for a few
releases, but eventually I'd like to get rid of that.
Thanks, Simon
OpenPGP_signature.asc
Description: OpenPGP digital signature
