Removing what a meta-package provided
Hello,
Here is the baseline: while "apt-get install kde" installs KDE, "apt-get
remove kde" does not remove anything. Power users know this, but it can be
disconcerting for novices, and every user could benefit from a way to say
"okay, enough played with <insert subsystem name>, now I want to remove it".
At this point, a small disclaimer: there is obviously nothing specific to
KDE here. Any maintainer that provides meta-packages in order to ease
proper installation of a coherent set of packages could or should also
provide an easy way to remove them. KDE is a large subsystem that comes
under the form of a sheer number of packages and a nice set of
meta-packages, so I thought that made it a good example for this
discussion.
Debian already provides a few solutions to automatically detect and remove
unwanted packages and libraries, but I argue users may expect something
more in some specific cases (i.e. with meta-packages). Aptitude and
debfoster keep track of packages that the user explicitly asked for and of
packages that were installed merely to satisfy dependencies. Installing and
then immediatly removing package kde with aptitude or debfoster should give
the user the possibility to revert to the situation before KDE's
installation. Hovewer, difficulties arise in more realistic situations,
like "install kde, install kdeaccessibility, install kate-plugins, remove
kde" => nothing removed here. aptitude/debfoster rely on the precise
history of installations and removals, and the user has to keep track of
what packages he installed, before he can "easily" revert it.
I think that an history-independent behaviour makes senses for
meta-packages. Let's imagine a "prerm" script for package kde. On running
"apt-get remove kde", the user would see this warning:
,--------------------------------------------------------------------.
| Warning: kde is just a meta-package |
+--------------------------------------------------------------------+
| What do you want to do: |
| 1_ Deinstall the whole KDE subsystem, that is [list of packages] |
| 2_ Only deinstall the kde meta-package, keep KDE packages (as this |
| meta-package occupies only 7 kB and eases future updates, it is |
| recommended to keep it: this is the next choice) |
| 3_ Keep the kde meta-package (abort this deinstallation) |
`--------------------------------------------------------------------'
Default choice would be 2, to match current behaviour. Actual messages
would obviously require further work, but you get the idea. Choice 1 would
have the same consequences whether kde-amusements had been installed before
kde or the other way around.
The non-automatic thus potentially difficult question is "what is part of
KDE?" Surely kdelibs. What about Qt? And libc6? (just to name three of
KDE's dependencies and to show that the answer is *not* fully deducible
from the dependency graph). So the maintainer will have to take some
subjective decisions, but my guess is that it will not be difficult to draw
the line in most cases, if not all.
Sorry for the long email. Is there anyone else "worried" by this issue?
--
Daniel Déchelotte
http://yo.dan.free.fr/
Reply to: