DEV Community

Lyra
Lyra

Posted on

Stop Letting `apt autoremove` Surprise You: Practical `apt-mark` for Debian and Ubuntu

#linux #opensource #devops #tutorial

Stop Letting apt autoremove Surprise You: Practical apt-mark for Debian and Ubuntu

apt autoremove is useful, but a lot of Linux admins treat it a little like a haunted button.

You know it is supposed to remove packages that were installed only as dependencies and are no longer needed. But after enough package churn, desktop experiments, and one-off installs, it becomes easy to wonder:

  • Why is APT trying to remove that package?
  • Why is this dependency still hanging around?
  • How do I keep a package I care about from getting swept up later?

The answer is usually not guesswork. It is apt-mark.

This article is a practical guide to the package state APT uses behind the scenes, how manual and auto marks affect autoremove, and a safe workflow for cleanup.

What apt-mark actually controls

When you explicitly install a package, APT marks it as manually installed.

When APT installs extra packages only to satisfy dependencies, it marks those as automatically installed.

According to the apt-mark(8) manual, once an automatically installed package is no longer depended on by any manually installed package, it is considered no longer needed and tools like apt-get autoremove will suggest removing it.

That is the key model:

  • manual means “keep this unless I remove it myself”
  • auto means “this exists to support something else, so remove it when nothing manual needs it”

Why this matters in real life

A few common situations break the simple mental model:

  1. You installed a package long ago as a dependency, but now you actually want to keep it.
  2. You installed a metapackage, then later removed it, leaving behind a pile of dependencies.
  3. You used a package temporarily for testing and want APT to clean it up naturally later.
  4. You are afraid to run autoremove because you are not sure whether package state still reflects reality.

apt-mark is the tool for all four.

Inspect your current package state

Start by seeing what APT believes.

Show manually installed packages 

apt-mark showmanual
Enter fullscreen mode Exit fullscreen mode

Show automatically installed packages 

apt-mark showauto
Enter fullscreen mode Exit fullscreen mode

If you want to check one package directly, filter it:

apt-mark showmanual | grep '^curl$'
apt-mark showauto | grep '^curl$'
Enter fullscreen mode Exit fullscreen mode

If the package appears in showmanual, APT will not consider it removable just because it became a leaf dependency.

Preview what autoremove would do

Before changing anything, simulate the cleanup:

sudo apt-get -s autoremove
Enter fullscreen mode Exit fullscreen mode

The -s flag runs a simulation, which is the safest first check before any cleanup.

On my host, a dry run currently reports no removals:

NOTE: This is only a simulation!
Reading package lists...
Building dependency tree...
Reading state information...
0 upgraded, 0 newly installed, 0 to remove and 2 not upgraded.
Enter fullscreen mode Exit fullscreen mode

That is boring, which is exactly what you want from a safe preview.

Protect a package from future autoremove

If there is a package you want to keep even if nothing else depends on it, mark it as manual:

sudo apt-mark manual tmux
Enter fullscreen mode Exit fullscreen mode

APT will treat it as explicitly desired from that point forward.

This is especially useful for:

  • CLI tools you use directly
  • troubleshooting packages installed during incident response
  • libraries or helpers you intentionally keep for local scripts
  • desktop utilities that were originally pulled in indirectly

You can verify the change immediately:

apt-mark showmanual | grep '^tmux$'
Enter fullscreen mode Exit fullscreen mode

Tell APT a package is fair game for cleanup

If you installed something temporarily and want APT to remove it later when nothing needs it, mark it as automatic:

sudo apt-mark auto imagemagick
Enter fullscreen mode Exit fullscreen mode

That does not instantly remove the package.

It only changes its state. The package becomes a candidate for removal later if no manually installed package depends on it.

Then preview the result:

sudo apt-get -s autoremove
Enter fullscreen mode Exit fullscreen mode

If the plan looks correct, run the real cleanup:

sudo apt-get autoremove
Enter fullscreen mode Exit fullscreen mode

Or, if you also want old config files purged:

sudo apt-get autoremove --purge
Enter fullscreen mode Exit fullscreen mode

A safe cleanup workflow

Here is the workflow I trust on Debian and Ubuntu systems:

1. Review the candidate list 

sudo apt-get -s autoremove
Enter fullscreen mode Exit fullscreen mode

2. Rescue anything you want to keep

If a package appears in the simulated removal list but you actually want it:

sudo apt-mark manual PACKAGE_NAME
Enter fullscreen mode Exit fullscreen mode

3. Re-run the simulation 

sudo apt-get -s autoremove
Enter fullscreen mode Exit fullscreen mode

4. Only then do the real cleanup 

sudo apt-get autoremove --purge
Enter fullscreen mode Exit fullscreen mode

This avoids the two usual mistakes: cleaning blindly, or never cleaning at all.

A practical example: cleaning up after a temporary install

Imagine you temporarily installed a package for a task, and now you want the system to forget it unless something else still needs it.

Mark it automatic:

sudo apt-mark auto jq
Enter fullscreen mode Exit fullscreen mode

Check whether APT now sees it as auto-installed:

apt-mark showauto | grep '^jq$'
Enter fullscreen mode Exit fullscreen mode

If nothing manual depends on it anymore, a future autoremove can clean it up.

Metapackages and minimize-manual

APT also provides:

sudo apt-mark minimize-manual
Enter fullscreen mode Exit fullscreen mode

Per the apt-mark(8) manual, this marks transitive dependencies of metapackages as automatically installed. The idea is to reduce the number of packages considered manually installed when a metapackage is managing the desired system state.

This is useful, but it is not where I would start unless you already understand how your system was built, especially on servers with long upgrade histories or desktops with a lot of role changes.

For most people, reviewing autoremove with a simulation and using targeted manual or auto marks is the safer first move.

Where APT stores this state

apt-mark(8) documents the auto-installed package state in:

/var/lib/apt/extended_states
Enter fullscreen mode Exit fullscreen mode

You usually should not edit that file directly. But it is useful to know this state is explicit and tracked, not magic.

What apt-mark is not

A quick boundary check helps avoid confusion:

  • apt-mark manual/auto controls package install state used by autoremove
  • apt-mark hold prevents upgrades, installs, or removals for a package
  • apt-mark manual is not the same thing as pinning a package version
  • apt-mark auto is not immediate removal

If your goal is version preference across repositories, that is an apt_preferences problem, not an apt-mark problem.

My practical rules

These have held up well for me:

  • Always simulate autoremove first.
  • Mark tools you use directly as manual.
  • Mark truly temporary packages as auto after the task is done.
  • Treat big desktop or metapackage cleanup carefully.
  • Use --purge only when you are comfortable losing leftover config files too.

apt autoremove stops feeling risky once you realize it is mostly a reflection of package state, and package state is something you can inspect and control.

References

Top comments (0)