Hi, On Tue, May 03, 2016 at 11:55:06PM -0400, Daniel Richard G. wrote: > Recently, I was working in Ubuntu Xenial (apt version 1.2.10ubuntu1), > and observed this behavior: > > # apt-get -s install xubuntu-desktop bluez- | grep bluez > Package 'bluez' is not installed, so not removed > avahi-autoipd avahi-daemon avahi-utils bc blueman bluez:i386 bluez-cups > bluez-obexd brltty brltty-x11 catfish cheese-common colord colord-data > > I don't want "bluez" to be pulled in along with "xubuntu-desktop", so I > specify it with the trailing hyphen. But apt-get then says "okay, that's > fine, I'll install 'bluez:i386' instead." So I have to specify > "bluez:*-" in order to set it straight and get the desired effect. Please move this to a new (wishlist) bugreport – as I think we can do something about that (see below)… > This does not appear to be a desirable behavior, and I don't think it is > particularly defensible, either. As it is, most packages can be not- > installed with just the hyphen. It is only certain packages that, thanks > to dependency vagaries, can slip in via a foreign architecture and thus > need the wildcard. (Two more such packages are "libbonobo2-common" and > "pulseaudio".) > > I'd like to see "foo-" effectively mean the same thing as "foo:*-". > (Which seems to be basically what Carsten was requesting, albeit in a > somewhat different context.) … to a certain extend. We can't change 'foo-' to mean 'foo:*-' as for libraries (M-A: same) it would mean that you always remove all of them, while you perhaps just want to remove one of the set. More importantly through it is just inconsistent as all the other modifiers do not apply to a 'group' of packages either, its always a single package with a specific architecture (native by default) by default. That said, the problem with bluez above is that xubuntu-desktop recommends bluez (not checked, inferred from your message) and given that bluez:amd64 isn't installable, apt tries to install bluez:i386 because that is also satisfying bluez (as it is M-A: foreign). I think the resolver should realize that if bluez(:amd64) is forbidden from the installation everything which provides bluez(:amd64) [which is how M-A:foreign is implemented internally] is forbidden to step in for bluez(:amd64), too – but not forbidden on its own (which foo:*- does). That should capture the "common" case of M-A:foreign packages in "foo recommends bar", but would still allow picking off alternatives in cases like "foo recommends bar | bar:i386". Anyway, please split it off (cloning feels a bit wrong as it isn't overly related to the other long messages in this report) to a new bug for record keeping. Perhaps I even have some time later this week to look into implementing this… Best regards David Kalnischkies
Attachment:
signature.asc
Description: PGP signature