Re: Re: Bug#748936: apt doesnt understand architecture wildcards
On Wed, Jan 20, 2016 at 01:39:45PM +, 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 -- 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
Re: Re: Bug#748936: apt doesnt understand architecture wildcards
On Wed, Jan 20, 2016 at 03:17:18PM +0100, Bill Allombert wrote: > On Wed, Jan 20, 2016 at 01:39:45PM +, Colin Watson wrote: > > I think this is somewhat unfortunate, but it is the reality right now. > > Perhaps a good thing for somebody to work on would be reimplementing > > dpkg-architecture in C so that it could be moved to the dpkg binary > > package? > > As I understand, dpkg-architecture query the C compiler which is not > always avalaible. While that's true, it's partly just because it's architecture-independent code. A compiled version could build that information into the object code without much trouble. -- Colin Watson [cjwat...@debian.org]
Re: Re: Bug#748936: apt doesnt understand architecture wildcards
2016-01-20 15:12 GMT+01:00 Bálint Réczey : > Hi, > > 2016-01-20 14:39 GMT+01:00 Colin Watson : >> 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. >> dpkg doesn't currently provide a way to make this kind of query without >> development tools installed. It's also probably not trivial to move it >> because its current implementation relies on dpkg's Perl modules, which >> also aren't part of the core dpkg binary package. >> >> I think this is somewhat unfortunate, but it is the reality right now. >> Perhaps a good thing for somebody to work on would be reimplementing >> dpkg-architecture in C so that it could be moved to the dpkg binary >> package? > I may check that option, but in the meantime I'm thinking about patching > APT to recognize musl-linux- and hardened1-linux- as linux-any. I have filed #812212 with a possible fix for handling at least the -- patterns. Cheers, Balint
Re: Re: Bug#748936: apt doesnt understand architecture wildcards
On Wed, Jan 20, 2016 at 01:39:45PM +, 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. > dpkg doesn't currently provide a way to make this kind of query without > development tools installed. It's also probably not trivial to move it > because its current implementation relies on dpkg's Perl modules, which > also aren't part of the core dpkg binary package. > > I think this is somewhat unfortunate, but it is the reality right now. > Perhaps a good thing for somebody to work on would be reimplementing > dpkg-architecture in C so that it could be moved to the dpkg binary > package? As I understand, dpkg-architecture query the C compiler which is not always avalaible. Cheers, -- Bill. Imagine a large red swirl here.
Re: Re: Bug#748936: apt doesnt understand architecture wildcards
Hi, 2016-01-20 14:39 GMT+01:00 Colin Watson : > 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. > dpkg doesn't currently provide a way to make this kind of query without > development tools installed. It's also probably not trivial to move it > because its current implementation relies on dpkg's Perl modules, which > also aren't part of the core dpkg binary package. > > I think this is somewhat unfortunate, but it is the reality right now. > Perhaps a good thing for somebody to work on would be reimplementing > dpkg-architecture in C so that it could be moved to the dpkg binary > package? I may check that option, but in the meantime I'm thinking about patching APT to recognize musl-linux- and hardened1-linux- as linux-any. For the record there is a matching logic in dose3 which works well in my use case: https://anonscm.debian.org/cgit/pkg-ocaml-maint/packages/dose3.git/tree/deb/architecture.ml Cheers, Balint
Re: Re: Bug#748936: apt doesnt understand architecture wildcards
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. dpkg doesn't currently provide a way to make this kind of query without development tools installed. It's also probably not trivial to move it because its current implementation relies on dpkg's Perl modules, which also aren't part of the core dpkg binary package. I think this is somewhat unfortunate, but it is the reality right now. Perhaps a good thing for somebody to work on would be reimplementing dpkg-architecture in C so that it could be moved to the dpkg binary package? -- Colin Watson [cjwat...@debian.org]
Re: Re: Bug#748936: apt doesnt understand architecture wildcards
Hi, On 06/04/2014 03:41 AM, Guillem Jover wrote: > Hi! > > On Sun, 2014-05-25 at 22:04:48 +0200, Bernhard R. Link wrote: >> * Johannes Schauer [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" ... > * 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. Cheers, Balint
