On 11/28/2012 05:25 PM, Guillem Jover wrote: > Precisely because it's the <cpu> and not the <arch>, as can be seen from > «dpkg-architecture -aarmel -qDEB_HOST_ARCH_CPU». I can well concede that > though, that this might not seem intuitive, but then lots of things in > dpkg architecture names aren't either (like the omission of the kernel > for Linux architectures, or that mipsel does not have mips as cpu...). > > Something that we could do is warn if a non-wildcard component of a Debian > triplet is unknown, like the armel in any-armel there. Also maybe try > to clarify these things a bit more in the man page. I can work on that.
Yes, but that means that one cannot discriminate between arm and armel when using the <os>-<cpu> syntax. I guess nobody expected to have the same <os> and <cpu> with different ABIs; Policy seems to have the same bug: ---- 11.1.1: Architecture wildcards A package may specify an architecture wildcard. Architecture wildcards are in the format any (which matches every architecture), os-any, or any-cpu. ---- The footnote there claims that the libc and ABI is implied by these two values: ---- Internally, the package system normalizes the GNU triplets and the Debian arches into Debian arch triplets (which are kind of inverted GNU triplets), with the first component of the triplet representing the libc and ABI in use, and then does matching against those triplets. However, such triplets are an internal implementation detail that should not be used by packages directly. The libc and ABI portion is handled internally by the package system based on the os and cpu. ---- This might get interesting results with x32 as that is another ABI for amd64 and people might actually use any-amd64... % dpkg-architecture -ax32 -iany-amd64; echo $? 0 Ansgar -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
