Bug#53951: apt-get should support '--prune' option to remove unused dependencies
Package: apt
Version: 0.3.15
Severity: wishlist
It would be nice if, whenever apt-get determines it should remove a
package, that it could also scan all of that package's dependencies
and remove them if they would be unused after removing the package
in question. This is sort of the opposite of what happens if you
'apt-get remove' a package where the package is a dependency of other
packages.
This would be particularly useful on dist-upgrades. Currently I have
to manually mop up a whole pile of unused GTK and GNOME-related shared
libraries every few dist-upgrades, as the shared-library-of-the-week
is usually replaced in a new package without removing the old one.
apt-get is smart enough to install the new library packages--it should
be smart enough to get rid of the old ones once every package on the
system is upgraded and using the new ones.
"--prune" could be disastrous on a system that had significant amounts of
software installed outside of dpkg's package management infrastructure.
It is only useful to users who do not install any software with
dependencies not managed by the Debian package management system (which
is surprisingly easy to do these days).
The exact semantics I would like to have for "--prune" are:
An "unused" package is a package which is currently declared
as a dependency of any package installed on the system and will not be
so declared after apt-get installs and removes packages. This means
that after the apt-get operation, "unused" packages are not listed in
any installed package's "Depends" or "Pre-Depends" field, (possibly also
"Recommends" or "Suggests"), the package does not list any installed
package in its own "Enhances" field, and the package is not Essential,
but any of these were true before the apt-get operation.
The set of "unused" packages recursively (or iteratively ;-) includes
any packages that would meet the criteria after all known "unused"
packages were also removed.
The initial set of "unused" packages must not include any packages that
would not be removed by the apt-get command, for reasons that should be
obvious.
An alternate set of semantics for "--prune", which I will call
"--strict-prune", is thus:
A "strictly-unused" package is a package which is currently declared
as a dependency of any package installed on the system which is to be
removed by the current apt-get operation. This means that after the
apt-get operation, "unused" packages are not listed in any installed
package's "Depends" or "Pre-Depends" field, (possibly also "Recommends"
or "Suggests"), the package does not list any installed package in its
own "Enhances" field, and the package is not Essential, but the package
was referenced in one of these ways by an installed package which is to
be removed by the current apt-get operation.
The set of "strictly-unused" packages recursively (or iteratively)
includes any packages that would meet the criteria after all known
"strictly-unused" packages were also removed.
The initial set of "strictly-unused" packages includes only packages
which are listed as dependencies of packages that would be removed by
the current apt-get command.
The primary difference between "--strict-prune" and "--prune" can be seen
when the dependency list of a package is changed when that package is
upgraded (e.g. to depend on 'libfoo1.2' instead of 'libfoo1.1', where
both 'libfoo1.1' and 'libfoo1.2' can be installed at the same time).
In this case, packages would be "unused" but not "strictly-unused."
"--prune" and "--strict-prune" will cause apt-get to, in addition
to the user's requested operations, remove all "unused" or
"strictly-unused" packages as defined above.
I personally prefer "--prune" to "--strict-prune", but "--strict-prune"
probably works better for people who have many locally compiled programs
on their system without dependencies entrered in /var/lib/dpkg/status.
OTOH, such people should probably not be using any form of '--prune', so
if it comes down to a choice between the two, pick '--prune'.
The remaining points should follow logically from the above.
1. apt-get --strict-prune install foo
If any packages are to be removed when installing or upgrading 'foo',
remove their "unused" dependencies too. With "--prune", also remove
packages that are no longer dependencies of installed packages (e.g.
when gimp is upgraded, remove the old libgimp1.1.XX library package).
2. apt-get --strict-prune remove foo
Remove "unused" dependencies of 'foo' as well as the usual packages
removed by this command (i.e. 'foo' and all of 'foo's dependents).
It is unlikely, but possible, that "--prune" would have different
behavior (e.g. if apt-get decides that it must install a package in order
to maintain dependencies?).
3. apt-get --strict-prune upgrade
Meaningless, since 'upgrade' never removes packages, and "strictly-unused"
packages must be dependencies of packages that are to be removed.
"--prune" here would remove packages that are no longer dependencies
of other packages after the upgrade, which could happen if a new version
of a package control file simply listed fewer dependencies than the old
version.
4. apt-get --strict-prune dist-upgrade
If any packages are to be removed by dist-ugprade, remove their
dependencies too. With "--prune", all packages which were listed as
dependencies before the upgrade that will not be listed as dependencies
after the upgrade are removed. Remove "unused" dependencies of any
packages that are removed for the usual reasons in a dist-upgrade
(i.e. due to conflicts or replacement).
5. apt-get --strict-prune dselect-upgrade
dselect theoretically handles dependencies anyway, so this should be
meaningless, but it should probably work like dist-upgrade or install
in practice.
6. apt-get --strict-prune {update,source,clean,autoclean,check}
Meaningless, since these do not install or remove packages.
-- System Information
Debian Release: potato
Architecture: i386
Kernel: Linux washu 2.2.13 #7 SMP Sat Dec 25 00:47:34 EST 1999 i686
Versions of packages apt depends on:
ii libc6 2.1.2-11 GNU C Library: Shared libraries an
ii libstdc++2.10 1:2.95.2-4 The GNU stdc++ library
Reply to: