Bug#673193: apt-get: should remove foreign arch packages even if arch suffix is missing
The new wishlist item has been submitted: bug #823625. -- Daniel Richard G. || sk...@iskunk.org My ASCII-art .sig got a bad case of Times New Roman.
Bug#673193: apt-get: should remove foreign arch packages even if arch suffix is missing
Hi David, On Wed, 2016 May 4 10:06+0200, David Kalnischkies wrote: > > Please move this to a new (wishlist) bugreport – as I think we can do > something about that (see below)… Great to hear :) > … 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. While I favor Carsten's proposal (if two arch packages are installed and I want to remove only one, I'd think it reasonable to add the arch specifier then), I don't find myself removing packages often enough for it to be a great concern. (Though if I'm, say, removing "foo" and "foo:i386" will remain installed, it would be nice for apt-get to point that out. In case I'm under the mistaken impression that I'm getting rid of "foo" completely.) > 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). "xubuntu-desktop" does recommend "bluez", but I think the issue is hairier than that, as I have not observed this behavior in scenarios involving fewer packages. As metapackages go, this one is gigantic, and if I had ever encountered a simpler example I would have given that instead. > 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". Hmm. If someone specifies "bluez:amd64-", they may intend for "bluez:i386" to be installable. But the resolver should be able to distinguish that from "bluez-", right? > 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… I am happy to have direction from you on this, as just discovering this report as relevant to the issue was non-trivial :] I will prepare and file a new wishlist bug report, then.
Bug#673193: apt-get: should remove foreign arch packages even if arch suffix is missing
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 signature.asc Description: PGP signature
Bug#673193: apt-get: should remove foreign arch packages even if arch suffix is missing
I've come across an issue that appears to relate directly to this discussion. I'd like to call it a bug, but it appears the maintainer(s) [or lack thereof] here may not agree. > > Maybe it is also because i regularly "remove" packages which are not > > installed in an install command as apt-get can be hinted this way > > that i don't want this package installed as a dependency of whatever > > i have requested. The inverse is also true if e.g. removing a bunch > > of packages by regex and just want to keep a few. (Not sure how many > > "normal" users know/use that through.) > > I'd assume the number of users that use apt-get in this way is > rather low ;) Count me as one of those users! I often want to install packages with many dependencies, and have most of the Recommends: go in as well (so --no-install-recommends is not appropriate), but still exclude a small number of unwanted packages. The syntax David alludes to, which appends a hyphen to the package name specified to "apt-get", is perfect for this. 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. 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.)
Bug#673193: apt-get: should remove foreign arch packages even if arch suffix is missing
* David Kalnischkies [2012-05-18 18:15 +0200]: On Fri, May 18, 2012 at 1:22 AM, Carsten Hey cars...@debian.org wrote: * David Kalnischkies [2012-05-17 14:41 +0200]: On Wed, May 16, 2012 at 10:16 PM, Carsten Hey cars...@debian.org wrote: No, dpkg is consistent in it's out-/input as is apt, so no bug. The out-/input just happens to be inconsistent between apt and dpkg. apt's command line tools do not provide a way to list the installed packages, so people using apt on the command line need to use for example dpkg to do so. synaptic users do not have this problem since it provides a complete user interface for the usual package management tasks, at least as long X as is not broken. I don't see the problem here. debian already has a commandline tool to list installed packages, as it has a tool to list the status of a package. ... This existing commandline tool lists installed packages in a way that can't be used to feed packages that should be removed to apt-get. Did you mean 'pkg:arch'? helps a bit, though. The problem with consistency is that in that case we would need to require a user to specify always the architecture if he deals with a M-A:same package. I dislike this because this changes overtime and isn't really easy to discover for a user. Yesterday libsame=1-1 installed fine, now i have to install libsame:native=1-2 to get what i want… (jftr: and the first in debian unreleased dpkg interface agreed with me) This would break debfoster (and many other scripts) way harder than the behavior now as the installation/removal of a library is a way more likely usecase and actually forces them to do a multiarch update, even through many script, howtos and even full-blown programs detailing how to install this and that will never really care about multi-arch (or at least they shouldn't). It also carries the problem that such a tool has to detect which version of APT it deals with (to know if it can/must use the architecture qualifier as e.g. squeeze includes already M-A:same packages). So, in short: You really don't want consistency between apt and dpkg. After reading a non-helpful dpkg error message like: | dpkg: error: --purge needs a valid package name but 'libconfig9' is | not: ambiguous package name 'libconfig9' with more than one installed | instance … and more importantly the need to display this message at all, especially if only one of the packages is installed and the other is removed, but not purged, I have to agree that consistency to the current dpkg interface is not a worthwhile goal. I still think that if the architecture qualifier is missing, installing should default to :native if the package is available there and otherwise try to install the package from a foreign architecture (as apt does), and that removing should default to all architectures. If both, apt and dpkg, would follow this, all the consistency and user interface problems I can think of would then vanish even with co-installable binary packages. Anyhow, since I can't convince you (choose between singular and plural as you like) to move a little bit into this direction, I presumably wouldn't be able to convince you and the dpkg maintainers to adapt apt and dpkg accordingly. apt and dpkg in Squeeze seem to work as expected if arch-qualified package names are passed to them. Since skip-upgrades are not supported anyway, I don't see why tools like debfoster would need to check the apt version. Maybe my concern for consistence inside apt-* is better understandable I think understand why consistency inside apt is worthwhile. Maybe it is also because i regularly remove packages which are not installed in an install command as apt-get can be hinted this way that i don't want this package installed as a dependency of whatever i have requested. The inverse is also true if e.g. removing a bunch of packages by regex and just want to keep a few. (Not sure how many normal users know/use that through.) I'd assume the number of users that use apt-get in this way is rather low ;) I don't know your setup, but it sounds like you have APT::Default-Release set, so apt just does what you said. apt-get source apt/unstable might does the right thing™. That shouldn't have changed too much in squeeze through either, so feel free to add a few more details. There are no apt preferences files and the part of the sources.lists that matches ^deb.*ftp.*debian\.org is: deb http://ftp.de.debian.org/debian squeeze main deb-src http://ftp.de.debian.org/debian sid main But it looks like this problem is fixed in Sid. I locally changed the version of the package debconf in a Sid chroot to a lower number and told apt to use a sources.list with only a deb-src Sid entry and no deb entry and was able to download the debconf source package. Doing the same on Squeeze failed to download the package. So all three issues I mentioned already have been fixed in Sid in a sane way
Bug#539340: Bug#673193: apt-get: should remove foreign arch packages even if arch suffix is missing
On Fri, May 18, 2012 at 1:22 AM, Carsten Hey cars...@debian.org wrote: * David Kalnischkies [2012-05-17 14:41 +0200]: On Wed, May 16, 2012 at 10:16 PM, Carsten Hey cars...@debian.org wrote: No, dpkg is consistent in it's out-/input as is apt, so no bug. The out-/input just happens to be inconsistent between apt and dpkg. apt's command line tools do not provide a way to list the installed packages, so people using apt on the command line need to use for example dpkg to do so. synaptic users do not have this problem since it provides a complete user interface for the usual package management tasks, at least as long X as is not broken. I don't see the problem here. debian already has a commandline tool to list installed packages, as it has a tool to list the status of a package. Reimplementing that just to have it in a tool with the prefix apt- sounds wrong. That said, we have longstanding dreams about an apt-list command which can list all packages matching a certain criteria, but it isn't even started and in my case longstanding means at least two years already, so i wouldn't hold my breath to have it available soon… (criteria being something like autoinstalled [currently: apt-mark showauto], not downloadable anymore and such things dpkg obviously can't list). I could invoke the i was first argument here, but the better argument is that dpkg only needs to specify an architecture if a M-A:same package is involved (and in that case it forces it) while apt has to deal with all packages being either native or foreign at all times, so if multiple architectures for a package are available it needs to know which one the user talks about. For convenience native is assumed by default for all packages … As a result of the inconsistency between apt's and dpkg's user interface, tools like debfoster (I CC'd the according 'please implement multiarch' bug) need to print package names with arch suffix on foreign architectures or its users will not always be able to remove the displayed packages using apt-get. It especially needs to pass the packages arch qualified to apt-get if it invokes it itself. If apt and dpkg would be consistent to each other, this behaviour could be documented in the policy so that other tools could rely on it, even in less widely used dpkg frontends. The problem with consistency is that in that case we would need to require a user to specify always the architecture if he deals with a M-A:same package. I dislike this because this changes overtime and isn't really easy to discover for a user. Yesterday libsame=1-1 installed fine, now i have to install libsame:native=1-2 to get what i want… (jftr: and the first in debian unreleased dpkg interface agreed with me) This would break debfoster (and many other scripts) way harder than the behavior now as the installation/removal of a library is a way more likely usecase and actually forces them to do a multiarch update, even through many script, howtos and even full-blown programs detailing how to install this and that will never really care about multi-arch (or at least they shouldn't). It also carries the problem that such a tool has to detect which version of APT it deals with (to know if it can/must use the architecture qualifier as e.g. squeeze includes already M-A:same packages). So, in short: You really don't want consistency between apt and dpkg. Maybe my concern for consistence inside apt-* is better understandable if you know that all apt-* tools nowadays share the same code to parse the commandline. Specifically the layer printing the 'Did you mean?' doesn't know what the user entered (in exchange, the code deciding about which package(s) the user talks doesn't know which action(s) will be performed). Maybe it is also because i regularly remove packages which are not installed in an install command as apt-get can be hinted this way that i don't want this package installed as a dependency of whatever i have requested. The inverse is also true if e.g. removing a bunch of packages by regex and just want to keep a few. (Not sure how many normal users know/use that through.) It's up to frontends to guess what the user meant, apt-* usually does what the user said, even through the user might be wrong. I personally think that is better than trying to tell the program that i am not the idiot the program thinks i am and therefore decides to do something else instead. At least for a tools as low-level as apt-*. I agree to what you wrote, but what I understand under the above does not completely match the behaviour of apt-*, for example, on stable with I agree that this is not always completely followed (hence the usually). Sometimes we really decide what we think might be best for the user and provide some crazy option-flag to work around it. APT would e.g. never download Translation files if we wouldn't try to detect a suitable default - for a few then quiet vocal users we get it wrong, but i can live
Bug#673193: apt-get: should remove foreign arch packages even if arch suffix is missing
On Wed, May 16, 2012 at 10:16 PM, Carsten Hey cars...@debian.org wrote: apt-get should remove foreign arch packages even if arch suffix is missing. I know that you disagree, but documenting unintuitive behaviour in the BTS in a good thing and this bug report explains why your reasoning is wrong. In that sentence you(r) is /me, just so that everyone gets who is meant. /me is the one implementing MultiArch in APT with its own mindset in 2010 as a GSoC project for debian after starting talking about it in 2009 after it was said that dpkg could have MultiArch enabled in 2 weeks. I never really asked others to agree with me, so you might actually find apt maintainers (depending on who you define as such, i am e.g. not one) who happens to agree with you. If you find such a someone who is willing to change it in time for wheezy (i think it is unreasonable to change it after wheezy release, but maintainer choice…) then by all means: Go for it. # dpkg --print-architecture amd64 # dpkg -l sc | grep ' sc' | tr -s ' ' ii sc 7.16-3 Text-based spreadsheet with VI-like keybindings # apt-get remove sc ... Package 'sc' is not installed, so not removed. Did you mean 'sc:i386'? 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. # dpkg -s sc | grep Arch Architecture: i386 Actually there are two bugs shown above. One is that dpkg -l omits important information. No, dpkg is consistent in it's out-/input as is apt, so no bug. The out-/input just happens to be inconsistent between apt and dpkg. I could invoke the i was first argument here, but the better argument is that dpkg only needs to specify an architecture if a M-A:same package is involved (and in that case it forces it) while apt has to deal with all packages being either native or foreign at all times, so if multiple architectures for a package are available it needs to know which one the user talks about. For convenience native is assumed by default for all packages -- i am just not enough of a man to require everyone to always specify an architecture. The other is that apt-get only removes foreign packages if either the arch suffix is added or if the package is not available on the native architecture. The reasoning by apt's maintainers is that in the above case sc:i386 must explicitly have been installed, which is obviously wrong since that a packages is available on one architecture now does not mean that it has been available on this architecture in the past and apt installs foreign packages if the architecture suffix is not added and the package does not exist on the native architecture. Again, it's just me with that reasoning with nobody publicly disagreeing with me so far who ended up changing it cause of that, but this doesn't make it a plural nor me an apt maintainer. (Just keeping facts straight) The logic consequence of this bug is through to remove the convenience of installing the foreign package in case no native package is available, not to add even more maybe the user meant something else logic… It's up to frontends to guess what the user meant, apt-* usually does what the user said, even through the user might be wrong. I personally think that is better than trying to tell the program that i am not the idiot the program thinks i am and therefore decides to do something else instead. At least for a tools as low-level as apt-*. Not sure if this is really a usability improvement. Properly as useful as removing the native is default assumption. I am doing neither but maybe someone else… for me the multiarch topic is done simple because i don't have the energy to discuss the same thing for more than two years. I really don't know how Steve, Goswin and co could do this - and even far longer… (yes, i know, the obvious reason is: i am too weak) Best regards David Kalnischkies P.S.: Yeap, this no maintainer thing is by choice and i like it. And others should like it, too, as their is no need for a ctte… Just go and write patches, you don't have to care about me, i know how to compile my own apt if everything else fails. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#539340: Bug#673193: apt-get: should remove foreign arch packages even if arch suffix is missing
* David Kalnischkies [2012-05-17 14:41 +0200]: On Wed, May 16, 2012 at 10:16 PM, Carsten Hey cars...@debian.org wrote: apt-get should remove foreign arch packages even if arch suffix is missing. I know that you disagree, but documenting unintuitive behaviour in the BTS in a good thing and this bug report explains why your reasoning is wrong. In that sentence you(r) is /me, just so that everyone gets who is meant. Sorry for mixing this up. (i think it is unreasonable to change it after wheezy release, but maintainer choice…) That changing it after the release in unreasonable is a good point. Given the unreasonableness of a change after Wheezy's release and that documenting possibly unintuitive behaviour in the BTS of a package with several hundred bugs is not that sane, I think this feature request should be closed during freeze, or, if it is clear that apt will not be changed previously, soonish. No, dpkg is consistent in it's out-/input as is apt, so no bug. The out-/input just happens to be inconsistent between apt and dpkg. apt's command line tools do not provide a way to list the installed packages, so people using apt on the command line need to use for example dpkg to do so. synaptic users do not have this problem since it provides a complete user interface for the usual package management tasks, at least as long X as is not broken. If apt would provide a list sub-command, your explanation that this is not a bug in apt would be reasonable, nevertheless, this bug has severity wishlist, so it is indeed not a bug but a feature request ;) I could invoke the i was first argument here, but the better argument is that dpkg only needs to specify an architecture if a M-A:same package is involved (and in that case it forces it) while apt has to deal with all packages being either native or foreign at all times, so if multiple architectures for a package are available it needs to know which one the user talks about. For convenience native is assumed by default for all packages … As a result of the inconsistency between apt's and dpkg's user interface, tools like debfoster (I CC'd the according 'please implement multiarch' bug) need to print package names with arch suffix on foreign architectures or its users will not always be able to remove the displayed packages using apt-get. It especially needs to pass the packages arch qualified to apt-get if it invokes it itself. If apt and dpkg would be consistent to each other, this behaviour could be documented in the policy so that other tools could rely on it, even in less widely used dpkg frontends. The logic consequence of this bug is through to remove the convenience of installing the foreign package in case no native package is available, not to add even more maybe the user meant something else logic… Your logic seems to be different to mine, anyway, you prefer the current behaviour over both alternatives and I prefer the current and my preferred behaviour over what you mentioned above, thus, at least unless someone else answers, removing the described convenience would all but reasonable. It's up to frontends to guess what the user meant, apt-* usually does what the user said, even through the user might be wrong. I personally think that is better than trying to tell the program that i am not the idiot the program thinks i am and therefore decides to do something else instead. At least for a tools as low-level as apt-*. I agree to what you wrote, but what I understand under the above does not completely match the behaviour of apt-*, for example, on stable with unstable sources, apt-get source apt fails and there is no non-weird way to tell apt-get to do what it did in previous releases, except when you look up the version number previously. I would not ask apt-get to download its sources on a system with only unstable source entries in the sources.list if I did not want to get them. apt-cache show does not preserve the command line order in its output anymore. We already discussed installing essential packages automatically in the past. P.S.: Yeap, this no maintainer thing is by choice and i like it. This explains a lot :) I always wondered why you are not listed in the uploaders field. Regards Carsten -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#673193: apt-get: should remove foreign arch packages even if arch suffix is missing
Package: apt Version: 0.9.3 Severity: wishlist apt-get should remove foreign arch packages even if arch suffix is missing. I know that you disagree, but documenting unintuitive behaviour in the BTS in a good thing and this bug report explains why your reasoning is wrong. # dpkg --print-architecture amd64 # dpkg -l sc | grep ' sc' | tr -s ' ' ii sc 7.16-3 Text-based spreadsheet with VI-like keybindings # apt-get remove sc ... Package 'sc' is not installed, so not removed. Did you mean 'sc:i386'? 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. # dpkg -s sc | grep Arch Architecture: i386 Actually there are two bugs shown above. One is that dpkg -l omits important information. The other is that apt-get only removes foreign packages if either the arch suffix is added or if the package is not available on the native architecture. The reasoning by apt's maintainers is that in the above case sc:i386 must explicitly have been installed, which is obviously wrong since that a packages is available on one architecture now does not mean that it has been available on this architecture in the past and apt installs foreign packages if the architecture suffix is not added and the package does not exist on the native architecture. Carsten -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
