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
