Re: aptitude doesn't remove unused packages
On Wed 22 Apr 2020 at 22:13:36 (+0200), Urs Thuermann wrote:
> Debian's package management should remove packages that were installed
> automatically, if they are no longer needed. Unfortunately, that
> often seems to not work correctly. See this example on my Raspberry
> Pi running Raspbian jessie:
[Be aware that I'm two versions ahead of jessie, and have never used
either a PI or the Raspbian OS.]
> Some time in the past there were probably packages that needed
> gcc-4.8-base so it were installed automatically:
>
> # aptitude show gcc-4.8-base
> Package: gcc-4.8-base
> State: installed
> Automatically installed: yes
> Multi-Arch: same
> Version: 4.8.4-1
> Priority: required
> Section: libs
> Maintainer: Debian GCC Maintainers <debian-gcc@lists.debian.org>
> Architecture: armhf
> Uncompressed Size: 176 k
> Breaks: dehydra (<= 0.9.hg20110609-2), gcc-4.4-base (< 4.4.7), gcc-4.7-base (< 4.7.3),
> gcj-4.4-base (< 4.4.6-9~), gcj-4.6-base (< 4.6.1-4~), gnat-4.4-base (< 4.4.6-3~),
> gnat-4.6 (< 4.6.1-5~)
> Description: GCC, the GNU Compiler Collection (base package)
> This package contains files common to all languages and libraries contained in the GNU Compiler
> Collection (GCC).
> Homepage: http://gcc.gnu.org/
>
> But after many updates/upgrades no installed package needs
> gcc-4.8-base anymore but it hasn't been removed. If I check why it's
> still installed I get:
>
> # aptitude why gcc-4.8-base
> i cron Recommends exim4 | postfix | mail-transport-agent
> p courier-mta Provides mail-transport-agent
> p courier-mta Depends courier-authlib (>= 0.66.1-1)
> p courier-authlib Depends expect
> p expect Recommends tk8.6
> p tk8.6 Recommends xterm | x-terminal-emulator
> p gnome-terminal Provides x-terminal-emulator
> p gnome-terminal Recommends gvfs
> p gvfs Depends gvfs-daemons (< 1.22.2-1+deb8u1.1~)
> p gvfs-daemons Recommends policykit-1-gnome
> p lxsession Provides policykit-1-gnome
> p lxsession Recommends openbox | x-window-manager
> p xmonad Provides x-window-manager
> p xmonad Recommends libghc-xmonad-dev
> p libghc-xmonad-dev Depends libghc-unix-dev-2.6.0.1-7550b
> p ghc Provides libghc-unix-dev-2.6.0.1-7550b
> p ghc Depends libgmp-dev
> p libgmp-dev Recommends libstdc++-4.8-dev | libstdc++-dev
> p libstdc++-4.8-dev Depends gcc-4.8-base (= 4.8.4-1)
>
> That is there is one package (cron) installed that only recommends one
> of a list of packages none of which are actually installed.
OK. I don't think aptitude why will honour the -R¹ option, so it
will take that first step even though none of the packages is actually
installed. As far as your system is concerned, it looks as if the
guess as to which path to follow was a bad one, missing any package
that's installed in the whole chain.
> Then
> there is a long list of Provides, Recommends, and Depends, all of
> which are pointless since the root of all this isn't installed. At
> the end of that long list is gcc-4.8-base and that makes aptitude
> think it should keep that package? Strange.
No, the chain exists using its criteria, so it reports it.
> (BTW, this is a router running a very minimal installation, therefore
> I don't want any X11, graphical, desktop, window-manager, Haskell, C++
> devel stuff on it.)
>
> Even calling apt-get autoremove explicitly doesn't remove that
> package:
>
> # apt-get autoremove
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
>
> I regularly observe things like this, not only on Raspbian, but also
> on Debian stretch for amd64 which runs on my server machine.
The cause could be the same. (I'm not certain which installers use
which resolver, but there is more than one.)
On Thu 23 Apr 2020 at 00:12:43 (+0200), Urs Thuermann wrote:
> The Wanderer <wanderer@fastmail.fm> writes:
>
> > if you
> > want to know "what's the dependency chain which is keeping this from
> > being safe to remove?", you're probably better off running 'apt-get
> > --dry-run remove [packagename]', and seeing whether the result wants to
> > remove anything that you care about.
>
> Well, I usually just call aptitude purge without --simulate because I
> want unneeded packages to be really removed and aptitude asks for
> confirmation if it would need to remove more packages. Here, with -s,
> but you can see that gcc-4.8-base is really not needed by anything.
>
> # aptitude remove -s gcc-4.8-base
> The following packages will be REMOVED:
> gcc-4.8-base
> 0 packages upgraded, 0 newly installed, 1 to remove and 0 not upgraded.
> Need to get 0 B of archives. After unpacking 176 kB will be freed.
> Would download/install/remove packages.
>
> > 'apt-get autoremove' deals only with packages which are marked as
> > auto-installed; for undetermined reasons, some packages which you
> > wouldn't expect to be get marked as manual. 'apt-mark showmanual' will
> > list all packages which are flagged as manually-installed.
>
> But as I showed in my first mail, gcc-4.8-base *is* auto-installed:
>
> # apt-mark showmanual | grep gcc
> #
>
> Despite this, apt-get autoremove doesn't remove it.
(insert same explanation as above.)
> > One thing I habitually do nowadays, to minimize this type of problem, is
> > to also run
> >
> > # apt-get remove $(deborphan)
> >
> > and interleave that back and forth with 'apt-get autoremove' calls until
> > neither one of them wants to remove anything anymore.
>
> That also doesn't help:
>
> # apt-get autoremove
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
(ditto.)
> # deborphan
> raspi-copies-and-fills
You probably need deborphan to be not nice with --ignore-suggests
and --ignore-recommends, but take care as you might be relying on
some Recommends even if you don't actually Depend on them.
> BTW, this also is strange since raspi-copies-and-fills is *not*
> auto-installed:
>
> # apt-mark showmanual | grep raspi
> raspi-copies-and-fills
I wasn't aware that deborphan cared any less whether a package was
installed manually or automatically. That's one of the reasons it only
considers libs by default: most people deliberately install many
packages that aren't depended on by anything (quite likely for some
of the computer's principal roles), but not libraries.
> That's why from time to time I look through the whole list of
> installed packages that look suspicious, i.e. auto-installed packages,
> especially with names matching lib*, *-common, and *-base, and that
> have multiple instances installed of the same name differing only in
> version. It seems there is no other reliable way to get rid of some
> old stuff :-(
I'm not sure why this necessarily concerns you more than deborphan.
For example, elinks depends on liblua5.1-0 whereas vim-gtk depends
on liblua5.2-0.
> > This doesn't 100% address the issue, but it will deal with more of it
> > than you might think.
> >
> > Does the 'deborphan' command report gcc-4.8-base, in your case?
>
> No, as shown above.
Try adding the options.
¹ To be fair, it says the option affects installation. Perhaps that
means only.
Cheers,
David.
Reply to: