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/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]