On Linux, almost everything is installed through packages. A package is an archive that contains a piece of software, its configuration files, and the list of what it needs to work. The package manager is the program that fetches these archives from a repository, resolves the dependencies, and keeps track of what is installed. This page gives you the mental model common to all these tools, then points you to the guide for the one you use.
What you will learn
- Understand what a package manager really does, beyond the
installcommand - Tell apart package, repository, dependency and metadata
- Recognise the five big families and know which one runs on your server
- Choose between the native tool and a universal manager depending on the context
The three notions to grasp before the commands
Every command you will type relies on three notions. Confusing them is the source of most beginner mistakes.
The repository is a server that hosts your distribution's packages. It is declared in a configuration file (/etc/apt/sources.list.d/ on the Debian side, in deb822 format on Debian 13 and Ubuntu 24.04, /etc/yum.repos.d/ on the RHEL side). Your machine only knows the software of the repositories it has declared: that is why a package can be "not found" even though it exists.
The metadata is the repository's index: the list of packages, their versions and their dependencies. Your machine keeps a local copy, and that copy ages. That is the whole point of apt update or dnf makecache: refreshing the index before installing. An apt install failing on a package that does exist is almost always a stale index.
The dependency is the link between packages. Installing a web server often pulls in about ten libraries. The manager computes this tree for you, and that is precisely where it can fail when two packages require incompatible versions of the same library.
The five native managers
Each distribution has its manager, suited to its package format and its update policy. They are not interchangeable. The table below tells you which one concerns you, and the detailed guides take over.
| Manager | Distributions | Format | Guide |
|---|---|---|---|
| APT | Debian, Ubuntu and derivatives | .deb | APT |
| DNF | RHEL, AlmaLinux, Rocky, Fedora | .rpm | DNF |
| Zypper | openSUSE, SLES | .rpm | Zypper |
| Pacman | Arch Linux and derivatives | .pkg.tar.zst | Pacman |
| APK | Alpine Linux (very common in containers) | .apk | APK |
The three basic operations look alike everywhere, only the syntax changes. On a Debian or Ubuntu server:
sudo apt update # refresh the repository indexsudo apt install nginx # installsudo apt remove nginx # uninstallOn RHEL, AlmaLinux or Rocky, dnf does the same thing, and refreshes its index automatically once it has expired: 24 hours on AlmaLinux 10 repositories (metadata_expire=86400, measured on 30 September 2026). An explicit update is therefore unnecessary there:
sudo dnf install nginxsudo dnf remove nginxBeware the false friend: apt update and apt upgrade do not do the same thing. apt update refreshes the repository index, apt upgrade (like dnf upgrade) updates the installed software. Many beginners run apt update believing they are patching their system, and patch nothing at all.
Universal package managers
When working across several distributions, juggling between syntaxes becomes tedious, and deployment scripts fill up with conditions. Universal managers offer a common layer, with very different philosophies.
Nix is the most complete, and the most demanding. Each package is stored in /nix/store/ under a hash computed from all its dependencies. Two versions of the same software coexist without conflict, each change creates a generation you can go back to, and the same configuration produces the same result on two machines. It works on any distribution and on macOS.
# enable first in ~/.config/nix/nix.conf:# experimental-features = nix-command flakesnix profile add nixpkgs#htop # installnix shell nixpkgs#jq # try without installingnix profile history # show the generationsThese commands of the new nix interface remain behind a flag: on Nix 2.35.2, the slightest command fails with experimental Nix feature 'nix-command' is disabled as long as the line above is missing. The same version flags nix profile install, still quoted by many tutorials, as a deprecated alias of nix profile add.
Flatpak and Snap meet another need: distributing desktop applications with their dependencies embedded and sandbox isolation. On a server, their interest is marginal. Homebrew, coming from macOS, is widely used to install development tools in the user's directory, without touching the system.
Choose according to the context
The right tool depends less on the distribution than on what the machine must guarantee: tracked patches, strict reproducibility or a workstation you do not want to clutter. The table reads from top to bottom, from the most constrained to the freest.
| Context | What I recommend |
|---|---|
| Production server | The distribution's native tool, without exception |
| Script deployed on several distributions | The native tool, with family detection; or Nix if reproducibility comes first |
| Workstation, development tools | Homebrew or Nix, which do not clutter the system |
| Strict reproducibility requirement | Nix, and possibly NixOS |
| Container | The base image's manager, almost always APK or APT |
Troubleshooting
Package failures look alike from one distribution to the next, and half of them come from a stale index or a badly declared repository. First look for the line whose message matches what you are reading: the right-hand column points to the detailed guide when the repair takes more than one command.
| Symptom | Probable cause | Solution |
|---|---|---|
Unable to locate package although the package exists | Stale local index, or undeclared repository | sudo apt update, then check the declared repositories |
| Unmet dependencies block the installation | Mixed repositories, or a third-party package installed by hand | Fix broken dependencies |
| The installed package is not at the expected version | The distribution freezes versions per branch | Check the available version with apt policy or dnf info |
| Software installed by hand is never updated | It is outside the manager's scope | Repackage it, or install it from a repository |
Could not get lock | Another package operation is in progress | Wait for it to finish, or identify the process holding the lock |
Key points
- A package manager does three things: talk to a repository, resolve dependencies, and keep track of what is installed.
apt updaterefreshes the index, it updates nothing. It isapt upgradethat applies the patches. The confusion is frequent and has heavy security consequences.- Five families cover the essentials: APT, DNF, Zypper, Pacman, APK. The operations are the same, only the syntax changes.
- Software installed outside the repositories goes off the radar: no updates, no security patches.
- In production, the native tool. Universal managers serve workstations, tests and reproducibility, not the server.
dnfrefreshes its index by itself once it has expired, unlikeapt: a difference that surprises when moving from one family to the other.
Put it into practice
The page has gone over the managers; the drill checks that you can use them without mixing them up, against the clock and without hints. Five tasks of installation, search and version locking, on the distribution you choose.