Craig Sanders wrote: > On Wed, 2 Dec 1998, Mitch Blevins wrote: > > > Craig Sanders wrote: > > > why are people proposing to clutter up dpkg and apt with "features" > > > that aren't needed? seems like a waste of time and effort to me, and > > > adds bloat to programs which do not need it. > > > > The proposed change would not change dpkg, just apt. It would not > > affect other programs 'which do not need it' so how could it bloat > > them? > > if it affects apt and/or dpkg and/or dselect, then it is affecting > program(s) which do not need it. > > i can't help but see this idea as just being an unnecessary and overly > complicated bit of bloat. A reasonable opinion. I also believe that features should not be added to apt without careful consideration. I just happen to think that this is one of the features where it would be warranted. The effects of the feature can be toggled off (and could even be off by default, if desired). > > > if you want to automatically remove packages which are no longer > > > needed by other packages, then surely the correct thing to do is to > > > have a (separate) tool which analyses the dependancy information and > > > outputs a list of packages which have no dependancies, optionally > > > offering a choice of removing them or not. > > > > This is not feasible. Most packages are not needed by other packages. > > This tool would spit out a list of (almost) every non-library package > > on the system. > > a command called grep can deal with this. we have a package naming > convention that library packages begin with "lib". if a lib package > fails to comply with policy then file a bug report. It's not just library packages. You also have documentation packages. You also have support packages that are neither libraries nor doc. Example: You might want tetex-extra to be removed if you remove tetex-bin. > > The only way to keep this list reasonable is to be able to > > differentiate which ones were installed explicitly and which ones were > > installed to satisfy a dependency. The only (reasonable) way to make > > this differentiation is to have apt keep track of it. > > i guess i just don't see much value in making that distinction, because > I don't ever want packages to be automatically uninstalled from my > system....i chose to install something, so i should be the one to chose > to uninstall it. A good reason to be able to toggle the behavior globally. > IMO this is particularly important for library packages - i may have > some script or program in /usr/local which will be broken if a library > package gets un-installed automatically. A good reason to have the 'Auto' status viewable from the APT interface and easily changeable for individual packages. > > > mostly, though, i can't see the point. what harm does it do to have > > > a few extra libraries installed on a system? it's not like they > > > actually cause any problems if they aren't used. > > > > The benefits of the proposed change expand beyond just cleaning up of > > crufty libraries. Easy package grouping is a side benefit. > > huh? aren't our packages grouped now? I think intention is for easy developer-defined grouping. For example: Gnome-Environment could be an empty package that depends on all the packages needed to have a 'complete Gnome experience'. But if you then decide you don't like it and remove the 'Gnome-Environment', it would also remove all the supporting packages that aren't used elsewhere on the system. I agree with your KISS anti-bloat standpoint for the most part, but I feel the proposed feature is both unobtrusive and highly desireable. -Mitch
Attachment:
pgpMa4rDoen1D.pgp
Description: PGP signature