Ubuntu – How to deal with `apt-get autoremove` in Ubuntu

aptaptitudeuninstall

(I can list more than 20 pages with kind of similar questions/concerns. But, I could not find any solution. So, please bear with me before marking this as duplicate.)

It's been almost three weeks that I switched from Windows to Linux (Ubuntu). I have been trying to find the right tools for my applications. So, I have been trying lots of different applications in Linux. As a result, I installed/removed a lot of applications using apt-get.

After one of these install/remove commands, apt-get suggested to run apt-get autoremove command. I did so and then I realized that it also removed some of my desktop applications and the look of my desktop environment completely changed. As I am not expert in Linux, I ended up spending time and re-installing it!

That was when I decided to never use apt-get autoremove again. I, then, searched around and came across deborphan which was recommended for removing orphan packages. So, instead of using apt-get autoremove, I was using below command to get rid of unwanted packages:

sudo deborphan --guess-all | xargs sudo apt-get -y remove --purge

This was just fine till recently that after running it, Qt-Creator stopped compiling my C++ code with the error cannot find -lGL. It was just fine right before using deborphan. Luckily, I was able to fix it by re-installing libgl1-mesa-dev package.

So, this, unfortunately, was also the end of my trust in deborphan.

Now, after couple of days of using neither of apt-get autoremove nor deborphan, here is the long list of packages that apt suggests for removal: 

 0 upgraded, 0 newly installed, 79 to remove and 0 not upgraded.> The following packages will be REMOVED:   fonts-wine
 geany-plugins-common gir1.2-evince-3.0 gir1.2-gconf-2.0
 gir1.2-nautilus-3.0 gir1.2-poppler-0.18 libboost-atomic1.62-dev  
 libboost-atomic1.62.0 libboost-chrono1.62-dev libboost-chrono1.62.0
 libboost-context1.62-dev libboost-context1.62.0  
 libboost-coroutine1.62-dev libboost-coroutine1.62.0
 libboost-date-time1.62-dev libboost-date-time1.62.0
 libboost-exception1.62-dev   libboost-fiber1.62-dev
 libboost-fiber1.62.0 libboost-filesystem1.62-dev
 libboost-graph-parallel1.62-dev libboost-graph-parallel1.62.0  
 libboost-graph1.62-dev libboost-graph1.62.0 libboost-iostreams1.62-dev
 libboost-locale1.62-dev libboost-locale1.62.0   libboost-log1.62-dev
 libboost-log1.62.0 libboost-math1.62-dev libboost-math1.62.0
 libboost-mpi-python1.62-dev libboost-mpi-python1.62.0  
 libboost-mpi1.62-dev libboost-mpi1.62.0
 libboost-program-options1.62-dev libboost-program-options1.62.0
 libboost-python1.62-dev   libboost-python1.62.0
 libboost-random1.62-dev libboost-regex1.62-dev
 libboost-serialization1.62-dev libboost-serialization1.62.0  
 libboost-signals1.62-dev libboost-signals1.62.0
 libboost-system1.62-dev libboost-test1.62-dev libboost-test1.62.0  
 libboost-thread1.62-dev libboost-timer1.62-dev libboost-timer1.62.0
 libboost-type-erasure1.62-dev libboost-type-erasure1.62.0  
 libboost-wave1.62-dev libboost-wave1.62.0 libboost1.62-dev
 libboost1.62-tools-dev libhwloc-dev libibverbs-dev libieee1284-3:i386 
 libnuma-dev libopenmpi-dev libpython3-dev libpython3.6-dev libwine
 libwine:i386 linux-headers-4.13.0-21 linux-headers-4.13.0-21-generic  
 linux-image-4.13.0-21-generic linux-image-extra-4.13.0-21-generic
 mc-data mpi-default-dev ocl-icd-libopencl1:i386 python-glade2         
 python3-dev python3.6-dev thunderbird-locale-en wine32:i386 wine64

I neither have the time nor the knowledge to go through this list and find out which package I do really need and which is fine to be removed.

I also tried to mark them all as "manual" with the hope that after doing so, apt-get autoremove can determine which are really orphan and unwanted to be removed. I used aptitude keep-all and it always freezes. I found that this is a bug supposed to be fixed but apparently is not.

Question:
What is the safest approach to remove unwanted applications/libraries in Ubuntu that does not involve checking all of the packages and their dependencies one by one?

Best Answer

The rules for autoremoval are actually quite simple.

The specific answer to your question "safest approach to remove unwanted applications/libraries in Ubuntu that does not involve checking all of the packages and their dependencies one by one" is: Let Apt do it's job. You can do that when you better understand how apt makes it's decisions. For most new users, this is a normal part of the learning curve. So let's discuss Apt logic....

Apt has no idea if you are using a package or not. It's not psychic. It only knows each package's dependencies, and what you tell it. In order for any package to be eligible for autoremoval (orphaned), it must meet two criteria:

  1. It must be apt-marked as auto (instead of manual)
  2. No manual package depends --directly or indirectly-- upon the package.

There are three complicating behaviors that confuse users.

  1. Apt remembers which packages you explicitly install and marks those packages manual. All other dependencies are marked auto.

  2. The Ubuntu installer marks ALL initial packages on a fresh install manual. This is to keep new folks from accidentally removing huge slabs of their system.

  3. Kernel packages operate slightly differently due to a bit of Ubuntu script-fu.

That's it - two rules and three special behaviors. Everything else is plain old logic.

Let's look at a couple common examples to see how those rules and behaviors apply.

Example #1: sudo apt install foo libfoo

It's fairly obvious that anything called libfoo is probably a dependency of foo. And apt knows that, too. However, we explicitly told apt to install libfoo - it will be marked manual, and won't be eligible for autoremoval. Had we instead said only sudo apt install foo and let apt calculate the dependencies, then libfoo would be (properly) marked auto and would become eligible for autoremoval when foo is removed.

Example #2: sudo apt remove ubuntu-desktop

If you build up an Ubuntu system from a minimal image, or if you install LAMP stacks or new Desktop Environments after the initial install, then Metapackages like ubuntu-desktop are great - the whole stack in one command. But look at it from apt's point of view: A single manual package and dozens (hundreds) of auto dependencies. The moment you uninstall the metapackage due to trying a different application...well, you get the idea.

The way out is to simply mark your key top-level applications as manual:

sudo apt install foo       // Even if foo is already installed
sudo apt-mark manual foo   // Does the same thing
sudo apt-mark auto libfoo  // Makes libfoo eligible for autoremoval someday when foo gets removed
sudo apt remove foo        // Apt will remove foo *regardless* of apt-mark

Remember that apt-marking simply tells apt which packages are your top-level applications ineligible for autoremoval - it does NOT protect them from human folly.

The easy way to browse an autoremoval list for most folks is to simply look for top-level key application packages - your email client, your web browser, your IDE, your favorite game. Look for foo, ignore libfoo. When one does slip by and get removed, simply reinstall it - remember that telling the system to install a package marks it manual. However, your particular use case is more complicated since you compile software and use -dev packages. There is no magic solution for you (sorry) - you must take the time to learn which packages are important to you...just like the rest of us did.

Caveat: All this applies to deb packages from the Ubuntu repositories. If you add a lot of weird packages from someplace else, then there is more package housekeeping you must do. Remember that apt has no knowledge of nor control over pip, snap, flatpack, appimage software, downloaded binaries or scripts, or compiled code.

Related Question