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 <email@example.com> 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
> 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