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.
