Re: Bug#748936: apt doesnt understand architecture wildcards
* Guillem Jover <guillem@debian.org> [140604 03:42]:
> * 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.)
That assumes that dpkg knows the arechitecture already on the system you
need the information.
Take for example something looking at build dependency information to
queue builds on other systems. Or something creating a partial mirror of
a repository containing what is needed to build specific packages on
some architectures. If the only way is "call dpkg-architecture" then
this host needs to run the newest dpkg in order to be able to also
be able to handle new architectures. And on infrastructure hosts you
usually prefer to just run unmodified stable.
> * 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.
> * Matching on cpu instead of arch name, was the logical route once
> the architectures had been expanded into their normalized forms
> (the Debian triplets).
The question is: Why should the wildcards be able to match about details
only visible in the triplets.
A wildcard that just matches "Debian architecture without the kernel"
would be much easier to implement and not need additional knowledge
(except some easy to builtin "if there is no - then it is an implicit
"linux-*").
> * 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.)
Indeed, while it makes adding architectures similar to existing ones
a bit easier, it might make creating new architectures that much harder
in return (due to needing a patched dpkg even on other architectures
first).
And is one even able to express things like "only build depend on this
on armhf but not on armel"?
> 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.
At least I'd suggest to not allow it in the Debian archive yet. Not
everything dpkg supports must be allowed by policy. (Like upper case
letters in package names).
Bernhard R. Link
--
F8AC 04D5 0B9B 064B 3383 C3DA AFFC 96D1 151D FFDC
Reply to: