Don't just "apt autoremove" packages

CaffeineAddict

CaffeineAddict

Well-Known Member
Joined
Jan 21, 2024
Messages
588
Reaction score
365
Credits
4,902
This is a short hint which I wish to share because I regret for not knowing it before.

When removing unneeded package we usually do sudo apt remove but if you're purge fanatic like me then you'll instead run:
sudo apt purge to also remove configuration files of that package.

And then if there are also dependent packages the above action will tell you this:

The following packages were automatically installed and are no longer required:
<snip> list of pacgages to autoremove goes here <snip>
Use 'sudo apt autoremove' to remove them.
Click to expand...

But sudo apt autoremove will not purge those dependencies! if you want to purge them as well then instead run:
Bash: 
sudo apt autoremove --purge

This way you're purging not only the package but also purging all it's dependencies, and that's the moment of truth you might want to know.
 


Thanks for that hint @CaffeineAddict .

An alternative to the option "autoremove --purge" is "autopurge".

The following is some ancillary observations which are based on an exploration which may appear long-winded, but tries to clarify some issues about dependencies.

The package that apt proposes to remove with the autoremove command, should have no packages that depend on it. If no packages depend on it, it's safe to remove since nothing else will be affected by its absence. That's the logic.

To determinine which packages depend on the package that is proposed for removal, one can use the option: rdepends, to the apt command.

The package slated for autoremoval may however depend on something else though. To see the packages that it depends upon, one uses the option: depends, to the apt command. Hopefully this will become clear in the following examples.

Here is a list of the packages proposed by the apt command for removal by use of the autoremove option a machine here.
Code: 
[root@min ~]# apt -s upgrade
<snip>
The following packages were automatically installed and are no longer required:
  libgphoto2-l10n libnsl-dev libpython3.12-minimal libpython3.12-stdlib libtirpc-dev linux-headers-6.6.13-amd64
  linux-headers-6.6.13-common linux-image-6.6.13-amd64 linux-kbuild-6.6.13 python3.12 python3.12-minimal
Use 'apt autoremove' to remove them.
<snip>

Taking as an example the package: libgphoto2-l10n, to see what it depends on:

Code: 
[ben@min ~]$ apt depends libgphoto2-l10n
libgphoto2-l10n
The output shows it depends only on itself.

When asking apt what depends on the package libgphoto2-l10n, the following appears:

Code: 
[ben@min ~]$ apt rdepends libgphoto2-l10n
libgphoto2-l10n
Reverse Depends:
  Recommends: libgphoto2-6 (= 2.5.31-2)
  Recommends: libgphoto2-6t64 (= 2.5.31-2.1)
The output shows that nothing depends on it, except itself. Since that's the case, it appears to be safe to remove.

In relation to the "Recommends" output which suggests some packages that are recommended for installation with libgphoto2-l10n, as recommended packages, they aren't essential and therefore won't break anything and can be ignored here.

Presumably in this installation, another package did depend on libgphoto2-l10n at some point, but that other package has either been removed, or upgraded rendering this package redundant and thus removable.

Looking at another of the packages recommended for removal, gives a different picture:

Here is what python3.12 depends upon:

Code: 
[ben@min ~]$ apt depends python3.12
python3.12
  Depends: python3.12-minimal (= 3.12.3-1)
  Depends: libpython3.12-stdlib (= 3.12.3-1)
 |Depends: media-types
  Depends: mime-support
  Depends: tzdata
  Breaks: python3-all (<< 3.6.5~rc1-1)
  Breaks: python3-dev (<< 3.6.5~rc1-1)
  Breaks: python3-venv (<< 3.6.5-2)
  Recommends: ca-certificates
  Suggests: python3.12-venv
  Suggests: python3.12-doc
  Suggests: binutils
The package python3.12 depends on a number of packages other than itself. as listed. The "Recommends" and "Suggests" can be ignored. The "Breaks" identify conflicts.

Here is a listing of what depends upon the python3.12 package:
Code: 
[ben@min ~]$ apt rdepends python3.12
python3.12
Reverse Depends:
  Depends: libpython3.12-testsuite (>= 3.12.3-1)
  Recommends: python3.12-minimal
  Depends: python3.12-venv (= 3.12.3-1)
  Recommends: python3.12-minimal
  Depends: python3.12-full (= 3.12.3-1)
  Suggests: python3.12-doc
  Depends: python3.12-dev (= 3.12.3-1)
  Depends: python3.12-dbg (= 3.12.3-1)
  Depends: python3-all
  Enhances: idle-python3.12
  Depends: idle-python3.12

The question arises, if so many packages depend on python3.12, why would it be slated for removal by autoremove?

The answer is that the output above is based on apt's database for the whole distro, and not just the installation in which the command is being run. When apt is asked about the current installation, it becomes clear why the package python3.12 can be removed. To restrict the output to the installation, the option --installed is used.

Here are the packages that python3.12 depends upon in this installation:

Code: 
[ben@min ~]$ apt --installed depends python3.12
python3.12
  Depends: python3.12-minimal (= 3.12.3-1)
  Depends: libpython3.12-stdlib (= 3.12.3-1)
 |Depends: media-types
  Depends: mime-support
  Depends: tzdata
  Breaks: python3-dev (<< 3.6.5~rc1-1)
  Recommends: ca-certificates
  Suggests: binutils

Here are the packages that depend on python3.12:
Code: 
[ben@min ~]$ apt --installed rdepends python3.12
python3.12
Reverse Depends:
  Recommends: python3.12-minimal
  Recommends: python3.12-minimal

It's clear now that nothing depends on python3.12, other than itself in this installation, hence it is safe to remove.

The upshot of this exploration is that it's not dependencies that will be removed by autoremove, neither, what the package depends upon, nor what depends upon that particular package, rather it's the determination of dependencies that apt does internally that controls which packages it will recommend for autoremoval. Rather than proposing packages be removed with dependencies ( as inferred in post #1), it's those packages which are no longer depended upon that are slated for removal.

The --purge or autopurge options to the apt command will indeed remove the configuration files of packages, but they are not dependent packages themselves, rather they are component files of the packages.
 
Last edited:
CaffeineAddict said:
@osprey
That was very informative!, thank you for explaining, certainly learned something new.
Click to expand...
Thanks. Your post #1 sparked me into trying to clarify dependencies for myself as well. In my case the issue started with the output of the command:
Code: 
apt list '?config-files'
This command lists package names that have config files from those packages that have been removed but have left the config files because the packages were not purged. The command uses an apt pattern (see man apt-patterns).

On running the command a small number of files were found whose packages had been removed, which then leaves the user with the choice of leaving those files or removing them.

I expect that the reason apt leaves the configuration files after an instance of removal of the package, is in case the user wants to reinstall the package. If the configuration file is still present, then the user will have the particular configuration of that file operating as before, instead of the default configuration of the package, which could be a considerable convenience for the user depending on the nature of the configuration. The suggestion made in post #1 actually enables the system to get a new clean default configuration if the deleted package gets re-installed, which may be preferable in most cases. Sometimes packages do get re-installed in upgrades despite having been removed, because they are a dependency of a new package that has been selected and installed.
 
Last edited:
osprey said:
In my case the issue started with the output of the command:
Code: 
apt list '?config-files'
Click to expand...
You read my mind lol, I've been asking myself this a few times but didn't investigate because I thought there is no way of purging config files of those packages which were removed but not purged.

I've run the command and there is quite a bit of left over config files in the output.
Is there any method to purge those configs without reinstalling removed package and then purging it?
 
CaffeineAddict said:
I've run the command and there is quite a bit of left over config files in the output.
Is there any method to purge those configs without reinstalling removed package and then purging it?
Click to expand...

I hope I understand this right. I use the following command:

Code: 
sudo apt-get purge $(dpkg -l | grep '^rc' | awk '{print $2}')

You can also do it in Synaptic package manager: Click on the “Status” button at the bottom of the left pane. If the category “Not installed (residual config)” shows is there, select it and remove everything that shows up in the list of packages.
 
CaffeineAddict said:
to also remove configuration files of that package.
Click to expand...
Names including "rc" often signify files or directories of files with code. Specifically, this code consists of commands that are meant to run when a program is executed. Indeed, that program can be an application, but it can also be a whole operating system. Sometimes some of these files get left behind after uninstall but you can also get rid of them by running

dpkg --list |grep "^rc"
dpkg --list |grep "^rc" |cut -d " " -f3
dpkg --list |grep "^rc" |cut -d " " -f3 |xargs sudo dpkg --purge
Click to expand...
 
You must log in or register to reply here.

Members online

Total: 658 (members: 7, guests: 651)

Latest posts

Top