* 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 :) Regards Carsten -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
