I've had a discussion in private email with Henry about this bug.
It's not entirely clear what bit him, but it sounds like the problem is
something I've seen scattered reports of on emailing lists and on the
Web. Here it is: since aptitude removes unused packages by default and
apt-get does not, users of apt-get (also synaptic) tend to have a lot of
unused packages built up on their system. The first time they run
aptitude, it suggests removing what in its eyes is a lot of cruft and
they go "WTF!?!" If they're lucky, someone tells them how to cancel the
auto flag on the packages in question or to run "aptitude keep-all".
This is obviously suboptimal. However, the removal of unused packages
is a core aptitude feature and I don't want to lobotomize it for the
sake of a one-time difficulty that people have when switching from
another package manager. In particular, turning it off by default is
not something I consider a reasonable option, because optional features
are not used by most people: I still get email from users telling me how
much they like the removal of unused packages in aptitude, despite the
fact that apt has exactly the same feature, it's just off by default!
One way to improve this situation is to somehow provide better
information about why packages are being removed. However, this is a
long-term goal: to really implement it well we might even need hooks in
apt or dpkg (or at least richer logging of their actions).
A shorter-term goal would be to alert the user when packages are being
removed as unused that aren't required by anything that's being upgraded
or removed. In fact: I just thought of that while I was writing this
email, and I'm really liking it. It probably works better for the
interactive interfaces than for the command-line, just because the
command-line spits out a lot of junk as a matter of course and it's easy
for the user to just hit "enter". (and unlike removing Essential
packages, I don't think we should introduce some annoying long-form
prompt to force the user to see that something out of the ordinary has
happened)
In any event, I don't think this is a release-critical bug. It might
arguably be a "normal" bug, but unless Henry objects I'm going to set
this to severity "wishlist". I was going to mark it "wontfix", but my
idea in the last paragraph is sounding like a really elegant solution to
this -- assuming it is what I think it is. I don't know when I'll have
time to actually implement it, but that's the usual order of things,
isn't it?
Thanks,
Daniel
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
