Heads-up: Switching internal dpkg arch representation to quadruplets
Hi!
Currently dpkg represents architectures internally as Debian triplets,
which have the inverse order as GNU triplets. One problem is that the
first element of the triplet encodes the ABI and the libc used, so we
have no way to wildcard one or the other, and this is becoming more
relevant with new arches targetting different libcs or same non-base
ABIs. This is one of the problems I'm tracking as part of the time-travel
fixes <https://wiki.debian.org/Teams/Dpkg/TimeTravelFixes>. :)
I never made the full triplets a "public interface" because I was worried
that exactly this could happen, and that's why this is hinted at in the
policy manual, but not explicitly documented.
This affects mostly triplet wildcards concerning the following ABIs:
eabi eabihf abin32 abi64 spe x32
So, where we could previously have the wildcard “uclibc-linux-any”,
it would not match “uclibc-linux-armel” because that is represented
internally as “uclibceabi-linux-arm”; or “gnu-any-any” would not match
none of “kfreebsd-armhf”, “mipsn32r6el”, nor “x32” for example.
This change fixes this so that we can match on each proper element of
the tuple by making it a quadruplet, and by making that a public
interface. So now we'll be able to match on any ARM EABI HF arch with
“eabihf-any-any-arm” or any glibc based arch “any-gnu-any-any” or with
its shorter form “gnu-any-any” and similar other combinations. In
particular this means that the semantics have changed and backwards
compatibility is somewhat "broken" if such undocumented wildcard triplets
were used; which they will match on more things (for example the above
mentioned “gnu-any-any”).
The current working branch for this can be found at:
<https://git.hadrons.org/cgit/debian/dpkg/dpkg.git/log/?h=pu/arch-debquadruplet>
which I'm planning to merge for dpkg 1.18.11, in principle targetted for
release this week. But if people see some serious problem with the plan,
I'm fine delaying it another release while any missing details are
hammered down?
This changes private module functions, and makes dpkg-architecture
additionally expose DEB_*_ARCH_ABI and DEB_*_ARCH_LIBC, which could
be stuff like eabi/eabihf/n32/spe/etc and gnu/musl/uclibc/etc
respectively. It also first versions the arch tables so that future
changes can be handled more gracefully, and second changes the internal
representation, which will affect some projects; the ones I'm aware of
are at least rebootstrap, botch, dose3 and dak (all maintainers BCCed).
I've not checked the archive this time around, I think we did so some
time ago, but I doubt we are using triplet wildcards there? Which would
be another possible cause of breakage.
Thanks,
Guillem
Reply to: