Ed Cogburn wrote: > Yes, this is what I was thinking of. Right now the only way to > 'associate' packages with one another, besides the section name, is to > use a common prefix in the name so they show up together in the same > place in dselect's screen. Imagine a user looking at the huge list of > packages (in X11 section) that start with 'x'. Yes, the dependencies > will auto-select most of the necessary packages if one is picked by the > user, but when I did this by picking xbase, I believe 'xterm' never got > auto-selected, nor is the user made aware of other 'significantly > related' packages like the other xfont and xserver packages. How would > a new user with little experience with Unix/X11 know he needs 'xterm'? > > There is one other 'association' issue that is getting worse. Imagine > selecting the gnome package suite. When I did this recently, I ended up > with more than *30* packages being selected for gnome support. Now > suppose the user wants to remove gnome to try out KDE, for example (lets > just assume they are mutually exclusive). There is no reasonable way > for this user to figure out which installed packages were installed for > gnome. I guess what I'm suggesting is that the packages need to > 'remember' *why* they were selected, by the user, or auto-selected > because of dependency requirements on a given package. When the user > goes to delete gnome from his system, the other packages that were > installed only because of dependencies, can 'inform' the user, somehow, > that they are no longer needed. One problem with auto-deinstallation of support packages is that you may have other packages that also use the same support package. You would have to grep the dependency database to ensure you weren't removing a library/package that was used elsewhere. Even then, you may have programs in /usr/local that are not tracked by dpkg and need one of those libraries. You also have support packages that are obviously useless by themselves (such as libraries), but what about the ones that are only 'semi-useless' by themselve. An example would be a documentation package. Suppose you want to have foo-doc installed without foo. (an avid reader) foo-doc would be part of the foo 'group', but can still be considered useful without foo. I think the best solution would be to be able to mark packages in dselect and dpkg, just like we currently have them marked as 'purge', 'hold', etc. We would just add a way to mark packages as 'installed-but-not-wanted-on-its-own-merits-so-uninstall-it-when-all- packages-needing-it-are-gone', or IBNWOIOMSUIWAPNIAG for short. -Mitch
Attachment:
pgp0THJgd6Y5I.pgp
Description: PGP signature