dpkg-archtecture -iany-armel does not work as expected, ie. it returns false on
armel:

% dpkg-architecture -aarmel -iarmel; echo $?
0
% dpkg-architecture -aarmel -iany-armel; echo $?
1

But returns true for -iany-arm:

% dpkg-architecture -aarmel -iany-arm; echo $?
0
% dpkg-architecture -aarmel -ignueabi-any-arm; echo $?
0

This happens as the actual comparison is done on triplets having the form

  gnueabi-linux-arm (armel)
  any-any-armel (any-armel)

However the man page for dpkg-architecture states: "-iarchitecture-wildcard"
and "architecture wildcard" is said to have the general form "<kernel>-<cpu>".

Ansgar

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.

Thanks,
Guillem

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

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.

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.

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