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 <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.
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 with that if the general benefit is big enough.
(aka: Exception proves the rule)
> 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.
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.
> apt-cache show does not
> preserve the command line order in its output anymore.
That was fixed in the 0.9 release and is no longer true.
(see 0.8.16~exp9 and #625960)
> We already
> discussed installing essential packages automatically in the past.
-o pkgCacheGen::Essential={all,native,installed,none}
native is the default. To have it really working you need to have it
in a config file through as it needs to be set at the time the binary
cache is generated. Documented in the bugreports alongside my general
warning that this is properly not a good idea.
Best regards
David Kalnischkies
P.S.: The devil in me just hopes we get co-installable binaries at some
point in debian. It will be so much fun to arch-qualify everything in dpkg.
(by hand i mean, APT already does this now as it was easier to implement)
Reply to: