Hi!
On Sun, 2014-05-25 at 22:04:48 +0200, Bernhard R. Link wrote:
> * Johannes Schauer <j.scha...@email.de> [140522 13:30]:
> > Debian policy 11.1.1 [1] and the associated footnote [2] allow
> > architecture wildcards of the form os-any and any-cpu. Apt seems to
> > equal "cpu" with "debian architecture" which is not correct. Here is an
> > example of correct matching:
> >
> > dpkg-architecture -aarmhf -iany-arm && echo "any-arm matches armhf"
> >
> > Apt would instead only match the deprecated "arm" architecture with
> > "any-arm". This doesnt seem to be a problem in practice though because:
> >
> > 1) apt does not check whether a source package can be compiled on the
> > current host architecture (it ignores the Architecture field of
> > source packages)
> > 2) all packages that have any-arm in their build dependency
> > architecture restrictions also include any-armel, any-armeb and
> > any-armhf
> >
> > Nevertheless, apt behaviour should reflect dpkg behaviour and naturally
> > policy. The correct behaviour is encoded in dpkg scripts/Dpkg/Arch.pm
> > and needs the files /usr/share/dpkg/triplettable and
> > /usr/share/dpkg/cputable to work correctly.
> Urgh. Really? This is far too complicated for most programs to implement
> properly. I'd suggest to rather fix dpkg (and also fix policy. The footnote
> describes absolutely nothing currently, and having such important fields
> a meaning that you cannot calculate without knowing what architectures
> the system finally using the package uses makes it unhandable).
The architectures in Debian are quite messy TBH, they have grown
rather organically, extended as needed while trying (in many cases)
to preserve backwards compatibility, and in some places they might
not seem coherent/uniform/etc, which might be close to the truth. If
I could start from scratch I'd probably define and implement them in
a very diffrent way.
The following are some of the weird properties that they have
currently:
* The Linux kernel is implicit in the architecture names.
* The glibc and ELF ABI are implicit in the architecture names.
* The architectures have a different cpu name (not just arch name)
depending on their endianness.
* Some architectures have a different base name when it comes to
their 32 and 64 bit variants.
* Sometimes the ABI is encoded in what would appear to be the
cpu name, others in an explicit libc/abi part of the tuple.
* Some architectures do not have equivalent on other kernels.
In any case, when it comes to the wildcards, I might be a bit fuzzy
right now on the details of the thought process at the time, and would
probably need to refresh my memory from my notes or emails from the
time. But AFAIR here's what I think was that thought process:
* We need a unique 1:1 bi-directional mapping from GNU triplets to
Debian architectures, some of the properties are hidden and need
to be internally expanded.
* Because those hidden properties are implicit, they require a table
which might not be known by other programs anyway.
* Other programs could “easily” use dpkg-architecture to check for
identity or a match. (This poses problems for programs that do not
want to either require dpkg around or to fork its tables.)
* Matching on cpu instead of arch name, was the logical route once
the architectures had been expanded into their normalized forms
(the Debian triplets).
* Matching on cpu instead of arch name, supposedly made adding support
distribution-wide for things like armel or lpia way easier. (This
might not have been worth it though.)
* If the wildcard is linux-any and the expanded form linux-foo does
not exist anyway, there's not much to make it coherent with. But
experience has demonstrated this still trips people over.
But, I agree this might seem confusing, and that's why I left #694630
open, because I want to deal with it some way or another. I'd have to
check if it would be feasible to match against the arch name instead of
cpu name, but even if there was no fundamental blocker there, changing
that now would imply a backward incompabitble change, and would require
at least someone going over the archive and taking care of any fallout
beforehand, and that does not cover out-of-archive packaging and
infrastructure, etc. So I'm not sure this seems appealing… but I'll
make a note of at least checking it.
Thanks,
Guillem
--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140604014159.ga19...@gaara.hadrons.org
