>> One problem with auto-deinstallation of support packages is that >> you may have other packages that also use the same support package.
Seeing how this problem is almost identical to the problem of memory allocation in a language like C or C++ (ie, memory-leaks vs. dangling-pointers), perhaps we can solve this one in a similar way. Perhaps we need some sort of garbage collection system... where dpkg maintains a list of apps that a support package is supporting. When the list is empty, the user can be offered the option of removing the packages. >> 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. Perhaps we could have a top-level menu item in dselect (up there with update, install, config...) called, say, "Clean-up". It could look for any (seemingly) unneeded support packages and let the user individually keep or jettison each one. >> 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. :) I had always considered the packages to be either "app" or "support".
