0

To find packages which have no installation candidate in my current repositories I ran:
apt-show-versions | grep "No available version in archive" (as recommended here)
I think it would be best if one was notified by the package manager that there are packages that were installed from a repository but are not in any of the current repositories anymore. That would be a (separate) issue with the package-manager though.

The command returned packages such as libgnome-keyring-common:all, bum and libgdbm3:amd64.

Now I'd like to find out which of these I can safely remove. I know that I installed some of those by by installing .deb files and these should not be removed.

I already tried running sudo apt-cache show libgdbm3, sudo apt show libgdbm3, sudo dpkg -p libgdbm3 but it only shows (latter command):

Package: libgdbm3
Priority: important
Section: libs
Installed-Size: 68
Maintainer: Debian QA Group <[email protected]>
Architecture: amd64
Multi-Arch: same
Source: gdbm
Version: 1.8.3-14
Depends: libc6 (>= 2.14), dpkg (>= 1.15.4) | install-info
Filename: pool/main/g/gdbm/libgdbm3_1.8.3-14_amd64.deb
Size: 30042
MD5sum: 4bd924fc8be5471a12d1e0204c74d6c3
Description: GNU dbm database routines (runtime version)
Description-md5: 900375b4641d82391c1c951c3b8647f6
Homepage: http://directory.fsf.org/project/gdbm/
Tag: role::shared-lib
SHA256: fbce0e2500aa970ed03665d15822265ff8d31c81927b987ae34e206b9b5ab0b6

and not how this package was installed. When I run sudo apt-get remove gdbm I get E: Unable to locate package gdbm.

How to properly clean out packages with no install candidate? And why are they not automatically removed or prompted to be removed when they got installed via a repo but are not in the current repos anymore? (Seems like this should be done every time repos are changed or an upgrade was done.)

System is Debian10/KDE.

Improve this question

1 Answer 1

Reset to default
3

I suggest marking all such packages as automatically installed:

apt-show-versions | awk '/No available version in archive/ { print $1 }' | xargs sudo apt-mark auto

Then apt autoremove will weed out those which can be removed; you’ll need to check the list and un-mark any packages you want to keep (apt-mark manual).

Packages can lose their “automatic” marker in a number of ways; one in particular is if apt install is ever used with them, e.g. to upgrade them or to try to figure out why they’re held back. Packages without the “automatic” marker won’t be candidates for removal unless another package conflicts with them. Even automatically-installed packages can stick around longer than intended: by default, if another package suggests them, they won’t be removed (which is a weaker dependency than any which would cause a package to be installed in the first place, by default).

Improve this answer
9
  • The problem with that is that it's also marking packages installed with .deb files for removal (like Zettlr and latest BackInTime). And it doesn't show why/how/when packages were installed. I guess your approach would be unmarking these packages manually.
    – mYnDstrEAm
    Jan 6, 2021 at 13:04
  • Like I said, “you’ll need to check the list and un-mark any packages you want to keep”. Other than the logs in /var/log/apt, the system has no memory of why packages were installed or where they were installed from (repositories or local packages).
    – Stephen Kitt
    Jan 6, 2021 at 13:11
  • 1
    gcc-6 isn’t present in Debian 10, that’s why apt-show-versions lists it as “No available version in archive”. It would have been installed from the repository on Debian 9, but it’s gone from Debian 10. The same goes for libva1. apt-mark showmanual does show packages marked as manual — “manual” means that the package was installed explicitly by the user, rather than as a dependency for another package. It has nothing to do with where the package came from.
    – Stephen Kitt
    Jan 6, 2021 at 18:49
  • 1
    If apt autoremove doesn’t offer to remove it, that means that another installed package depends on it, perhaps weakly. Attempting to remove it will tell you what the impact will be and give you a chance to cancel. And yes, it should be safe to remove!
    – Stephen Kitt
    Jan 6, 2021 at 19:35
  • 1
    You could also try deborphan. Other than that, ISTR a tool which will build a tree of unused packages, so you can start by deciding whether to keep packages at the top of the tree (thereby quickly deciding the fate of entire branches); but I don’t remember its name off-hand.
    – Stephen Kitt
    Jan 6, 2021 at 22:09

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .