Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #221824 > unrolled thread

aptitude doesn't remove unused packages

Started byUrs Thuermann <urs@isnogud.escape.de>
First post2020-04-22 22:30 +0200
Last post2020-04-23 13:20 +0200
Articles 7 — 5 participants

Back to article view | Back to linux.debian.user

Contents

  aptitude doesn't remove unused packages Urs Thuermann <urs@isnogud.escape.de> - 2020-04-22 22:30 +0200
    Re: aptitude doesn't remove unused packages The Wanderer <wanderer@fastmail.fm> - 2020-04-22 22:40 +0200
      Re: aptitude doesn't remove unused packages Urs Thuermann <urs@isnogud.escape.de> - 2020-04-23 00:20 +0200
        Re: aptitude doesn't remove unused packages David Wright <deblis@lionunicorn.co.uk> - 2020-04-23 04:30 +0200
      Re: aptitude doesn't remove unused packages Vincent Lefevre <vincent@vinc17.net> - 2020-04-23 03:40 +0200
    Re: aptitude doesn't remove unused packages Andrei POPESCU <andreimpopescu@gmail.com> - 2020-04-23 08:20 +0200
      Re: aptitude doesn't remove unused packages Vincent Lefevre <vincent@vinc17.net> - 2020-04-23 13:20 +0200

#221824 — aptitude doesn't remove unused packages

FromUrs Thuermann <urs@isnogud.escape.de>
Date2020-04-22 22:30 +0200
Subjectaptitude doesn't remove unused packages
Message-ID<zYual-1AL-1@gated-at.bofh.it>
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:

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.  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.
(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.

urs

[toc] | [next] | [standalone]

#221826

FromThe Wanderer <wanderer@fastmail.fm>
Date2020-04-22 22:40 +0200
Message-ID<zYuk2-1DX-9@gated-at.bofh.it>
In reply to#221824

[Multipart message — attachments visible in raw view] — view raw

On 2020-04-22 at 16:13, 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:
> 
> Some time in the past there were probably packages that needed 
> gcc-4.8-base so it were installed automatically:

<snip>

> 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

<snip>

> That is there is one package (cron) installed that only recommends
> one of a list of packages none of which are actually installed.
> 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.

I don't find 'aptitude why' very reliable in a lot of cases. If you want
to know "what's a dependency chain which might have led this to be
automatically installed?", or "what's a dependency chain which might
give you a reason to want to have this installed?", it's not bad; 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.

> Even calling apt-get autoremove explicitly doesn't remove that
> package:

'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.

> # 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.

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.

deborphan is a program (installed from a package of the same name) which
looks for dependency-type packages that aren't depended on by anything
else and reports their names. (There's apparently also a frontend
program called orphaner, mentioned in the package description, but I've
never used it.)

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?

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man.         -- George Bernard Shaw

[toc] | [prev] | [next] | [standalone]

#221829

FromUrs Thuermann <urs@isnogud.escape.de>
Date2020-04-23 00:20 +0200
Message-ID<zYvSO-2Fb-1@gated-at.bofh.it>
In reply to#221826
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.

> 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.
# deborphan
raspi-copies-and-fills



BTW, this also is strange since raspi-copies-and-fills is *not*
auto-installed:

# apt-mark showmanual | grep raspi
raspi-copies-and-fills


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 :-(

> 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.

urs

[toc] | [prev] | [next] | [standalone]

#221840

FromDavid Wright <deblis@lionunicorn.co.uk>
Date2020-04-23 04:30 +0200
Message-ID<zYzMK-505-3@gated-at.bofh.it>
In reply to#221829
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.

[toc] | [prev] | [next] | [standalone]

#221838

FromVincent Lefevre <vincent@vinc17.net>
Date2020-04-23 03:40 +0200
Message-ID<zYz0l-4pt-3@gated-at.bofh.it>
In reply to#221826
On 2020-04-22 16:39:00 -0400, The Wanderer wrote:
> I don't find 'aptitude why' very reliable in a lot of cases.

Ditto.

> 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.

I do this too, but for deborphan, I use: deborphan --ignore-suggests

Now, I think that alternatives and "Provides" can confuse the
resolvers.

To know why a package is not proposed for autoremoval while it should,
I suppose that a solution is to look at the apt-get trace, e.g.

  apt-get -o Debug::pkgAutoRemove=true -s autoremove

Good luck debugging this. :)

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

[toc] | [prev] | [next] | [standalone]

#221842

FromAndrei POPESCU <andreimpopescu@gmail.com>
Date2020-04-23 08:20 +0200
Message-ID<zYDnj-7aR-1@gated-at.bofh.it>
In reply to#221824

[Multipart message — attachments visible in raw view] — view raw

On Mi, 22 apr 20, 22:13:36, 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:
 
[...]

> 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)

This is controlled by the apt configuration options

    APT::AutoRemove::RecommendsImportant
    APT::AutoRemove::SuggestsImportant

See apt.conf(5) for how to adjust these.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser

[toc] | [prev] | [next] | [standalone]

#221856

FromVincent Lefevre <vincent@vinc17.net>
Date2020-04-23 13:20 +0200
Message-ID<zYI3E-1xe-1@gated-at.bofh.it>
In reply to#221842
On 2020-04-23 09:19:10 +0300, Andrei POPESCU wrote:
> This is controlled by the apt configuration options
> 
>     APT::AutoRemove::RecommendsImportant
>     APT::AutoRemove::SuggestsImportant
> 
> See apt.conf(5) for how to adjust these.

The user may want to keep Recommends.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web