On Wed, 2012-11-28 at 17:51:38 +0100, Ansgar Burchardt wrote: > 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:
You can discriminate them if you use the full Debian triplet form, as in gnueabi-any-arm for example. This is not documented (or outrigth discouraged, depending how you look at it), I don't remember why, though, I'll try to dig up notes/mails for possible reasons, otherwise I'll just document it. Something else that could be done probably is handle the two form tuples such as (any|linux)-<cpu> also as <os>-<linux-arch> if the <cpu> matches a known arechitecture, so that in case we'd had something like kfreebsd-armel, it would do the right thing (regardless of the GNU triplet using gnueabi-kfreebsd-arm or gnu-kfreebsd-arm, for example). I'd have to check for compatibility issue first though. > ---- > 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. > ---- Right, that's not entirely correct, for wildcards it's just assumed to be any-foo-bar or any-any-bar. When converting from GNU triplets there's always a 1:1 mapping, including the ABI. > 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 Well the amd64 vs x32 is even more "interesting" than arm vs armel, because the ABI of the former changes the bits among others, but does not change much preprocessor-wise, the only distinction is that on x32, __ILP32__ is defined. So anything checking for amd64 in any place needs to be hunted down and possibly updated for x32 anyway. regards, guillem -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
