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 <carsten@debian.org> wrote:
> > * David Kalnischkies [2012-05-17 14:41 +0200]:
> >> On Wed, May 16, 2012 at 10:16 PM, Carsten Hey <carsten@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
Reply to: