On Wed, Jan 20, 2016 at 01:39:45PM +0000, Colin Watson wrote: > On Wed, Jan 20, 2016 at 12:31:52PM +0100, Balint Reczey wrote: > > On 06/04/2014 03:41 AM, Guillem Jover wrote: > > > * Other programs could “easily” use dpkg-architecture to check for > > > identity or a match. (This poses problems for programs that do not > > > > I think making apt call dpkg-architecture for matching would be a good > > way of ensuring consistency with dpkg. Caching the results in a hash > > table would make matching even faster than it is currently. > > dpkg-architecture is in dpkg-dev, so not reliably usable at run-time.
Also, apt is trying to remain largely independent of the low-level package manager, so bluntly depending on it wouldn't be good, but … … apt could survive this (for now) as these architecture specifications can at the moment only be encountered in a) build-dependencies of source packages (effecting via python-apt also presumably stuff like dak) b) the commandline like 'apt install libfoo:linux-* foo:linux-any' (and aptitude uses it, too, for this) So, we could do that without too much pain, while keeping a fallback around for cases in which we don't have dpkg-architecture around for whatever reason as it doesn't effect apts primary operation (but might effect the primary operation of other tools which would need to be tested first). I wonder through if we aren't creating the debian version of a tar bomb (xkcd#1168) and to illustrate that a little quiz: dpkg-architecture -ai386 -ii386 true dpkg-architecture -ai386 -ilinux-i386 true dpkg-architecture -ai386 -iany-i386 true dpkg-architecture -aarmhf -iarmhf true dpkg-architecture -aarmhf -ilinux-armhf true dpkg-architecture -aarmhf -iany-armhf false dpkg-architecture -aarmhf -iarm false dpkg-architecture -aarmhf -ilinux-arm false dpkg-architecture -aarmhf -iany-arm true Now, given we want to go to <libc>-<kernel>-<cpu> lets see: dpkg-architecture -aarmhf -iany-linux-arm true dpkg-architecture -aarmhf -iany-any-arm true dpkg-architecture -aarmhf -ignu-any-arm false dpkg-architecture -aarmhf -ignueabihf-any-arm true And to cool off, think about what matches any-arm, linux-any, and if gnu-any is even supported and if what that matches… Truth be told, I would have died on 'any-armhf' already even through that is "obvious" as 'linux-armhf' is interpreted as a literal architecture, while 'any-armhf' is a pattern (just that neither dpkg nor the policy highlight that such a difference exists explicitly). Anyway, I somehow doubt it will be a good idea to trouble mere mortals with the difference between gnu and gnueabihf for matching proposes, so I wonder why we have to trouble them with the difference of armhf and arm depending on if that specification is a literal architecture or an architecture pattern – especially if the two are different only for some architectures… I would personally be more happy with any-armhf working (and a special case letting arm match all of the arms). So, I actually like how apt behaves currently as it just makes more sense in my head to expand armhf to gnu-linux-armhf and match it against gnu-any-armhf instead of gnueabihf-linux-arm and and gnueabihf-any-arm, but so be it – it tends to be more important to have a consistent answer in Debian than to keep me sane… (yeah, I know, that triplet makes perfect sense if you know history, Debian and arm – I just don't). I am therefore going to happily accept any patch flying my way implementing architecture wildcards differently if need be, but I am not going to do it myself mainly because I expect that to have fallout – not in apt, but in things using apt – and I don't have the energy (or the rights) to deal with such things efficiently. Best regards David Kalnischkies
signature.asc
Description: PGP signature
