Ed Cogburn wrote: > Mitch Blevins wrote: > > 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. > > > If dpkg kept track of all packages that depend on the one we are > talking about, it could 'know' when the package is no longer usefull and > is merely wasting space. > About usr/local: since we are talking about deb packages, I don't > belive there would be a situation where a deb package in the > distribution is dependent on a library that must be installed by the > user. Most deb packages in the distribution are dependent only on other > deb packages. The Netscape program that untill recently relied on a > 'installer' deb is an exception, though, but now NS is in deb packages > (in slink) so that exception is no longer valid.
I was speaking of the case where you have a /usr/local binary that depends on a shared lib that is in a .deb > > 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 guess that it would be up the maintainer to signify whether their > packages are support-only, or usable-on-their-own. The maintainer doesn't always know best. Centralization is bad. What if I want to build the latest foo from CVS that depends on the libfoo.deb package. I don't want foo.deb, but I do want the support package. The maintainer cannot forsee all the different scenarios. -Mitch
