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.
Reply to: