Re: What happens when Woody becomes Stable ??
Brian Nelson wrote:
> Using a contrived example:
>
> Suppose you wanted to install galeon, which depends on
> mozilla-browser. So, you did an 'apt-get install galeon', which installs
> mozilla-browser as well. Then you try galeon for a while, and also
> check out mozilla. You end up preferring mozilla, and use that as
> your regular browser. After a while, you 'apt-get remove galeon'
> since you no longer use it. However, according to your scheme,
> mozilla, which you wanted to keep, also gets removed.
That's why I mentioned having an option to prompt the user.
Additionally, one could limit automatic, unprompted removal to
libraries. So when you remove galeon, you get prompted to remove
mozilla, and you'd say no if you want to keep it. But if you do choose
to remove mozilla, then libnspr and libnss automatically go away if
nothing else depends on them.
There is also a category of non-library packages which people don't
usually use directly, and which one only installs to enhance other
programs -- metamail, for example. If you're using a mail client that
likes having metamail around, you install it, but then when you switch
to another client that doesn't care about metamail, it would be nice to
be told that it wasn't needed anymore, without also being told that
there are no dependencies on the Gimp, Emacs, xmms, etc. (apps which one
wants to use directly).
> It gets even trickier if you consider using dselect, since it's
> awfully hard to decide on whether a package was installed only because
> dselect asked, or because the user agreed with dselect's choices
> (ie. really wanted to keep those packages installed).
True, dselect complicates matters. You'd have to have some cooperation
between dselect and apt to make it work. And even then it would be
potentially problematic. Just the other day I had to do a lot of
hand-selecting of things in dselect to make it understand that I wanted
to switch from libsdl1.2 to the new libsdl1.2-debian. Poor dselect found
the situation rather confusing.
I suppose you'd really have to have two different kinds of selection in
dselect -- "Install this unconditionally" and "Install this only to
satisfy dependencies". The distinction would thus be left to the user,
at install time, rather than to software that could probably never be
clever enough to get it right 100% of the time.
> That's why it's really only useful to act as deborphan does, and only
> choose to remove libs that no longer are depended upon. Even that
> isn't foolproof, however.
Well, as long as all your software is packaged (nothing in
/usr/local/bin) and all every package's dependencies are right, it's
pretty safe. I don't remember ever seeing anything break because I
removed a library that deborphan said I didn't need anymore.
In practical terms, deborphan is adequate, I suppose. It would be nice
to be able to automate this kind of cleanup as part of the usual upgrade
procedure, though.
Craig
Reply to: