Linux Package Managers Compared

What a package manager actually does

A Linux package is a bundle of files (binaries, libraries, configuration, documentation, scripts) plus metadata: a name, a version, a description, a maintainer and — most importantly — a list of other packages it depends on. A package manager is the program that knows how to install, upgrade, remove and query those bundles, and how to deal with the dependency graph that runs through them.

Three concepts come up often enough to be worth defining once:

• Repository. A server (or set of servers) that hosts a collection of packages and an index describing them. Your distribution ships with one or more official repositories already configured; you can usually add more.
• Package format. The on-disk format of an installable package. .deb belongs to the Debian family; .rpm belongs to the Red Hat and SUSE families; Arch uses its own .pkg.tar.zst format.
• Dependency resolution. The process of working out the full transitive list of packages that need to be installed (or updated, or removed) to satisfy a request. This is the part that distinguishes a package manager from a glorified tar command.

The major package managers

apt — Debian, Ubuntu and their derivatives

apt is the front-end most users interact with on Debian-family distributions; underneath it sits a lower-level tool called dpkg that handles individual .deb files. The apt command unifies what used to be two separate tools (apt-get and apt-cache) and is what scripts and tutorials should use today.

Distributions that use apt include Debian, Ubuntu, Linux Mint, Pop!_OS, Raspberry Pi OS and Kali Linux. See the Ubuntu reference and Debian reference for context on those distributions.

dnf — Fedora, RHEL and rebuilds

dnf is the package manager for the Red Hat family. It is a Python-based front-end over rpm, the lower-level tool for installing individual .rpm packages. dnf replaced the older yum tool a number of years ago; on modern Fedora and RHEL releases, "yum" is just an alias.

Distributions that use dnf include Fedora, Red Hat Enterprise Linux, AlmaLinux, Rocky Linux and CentOS Stream. See the Fedora overview for context.

pacman — Arch Linux and its derivatives

pacman is the Arch package manager. It is deliberately small and fast and has its own command-flag conventions that look terse compared to apt and dnf. Each flag is a single capital letter, and several can be combined (so -Syu means "sync, refresh, upgrade").

Distributions that use pacman include Arch Linux, Manjaro, EndeavourOS and other Arch derivatives. See the Arch Linux overview for the wider context, including the AUR.

zypper — openSUSE

zypper is the command-line package manager for openSUSE (both Leap and Tumbleweed). Like dnf, it operates on .rpm packages, but its dependency-resolution engine (libzypp) is different and has its own behaviour for handling complex transitions.

Equivalent commands at a glance

The list below is the everyday cheat sheet. For each action, find your distribution's column and use that command.

Most of those commands need root, so add sudo in front when you're making changes (anything other than search, info or list).

If you maintain machines on more than one of these distribution families, the cross-distro update script wraps all four package managers behind a single command.

Worked example: installing the same thing on each distribution

To make the differences concrete, here is the same task — installing the htop process monitor and the GNU build essentials — on each family:

# Debian / Ubuntu
sudo apt update
sudo apt install htop build-essential

# Fedora
sudo dnf install htop @development-tools

# Arch Linux
sudo pacman -Syu
sudo pacman -S htop base-devel

# openSUSE
sudo zypper refresh
sudo zypper install htop -t pattern devel_basis

Two things to notice. First, the package names overlap heavily but not perfectly — what Debian calls build-essential is grouped slightly differently on each distribution. Second, every example pairs the install with a repository refresh; outside of Arch's combined -Syu, this is usually a separate step.

How they differ underneath

Dependency resolution

All four package managers resolve dependencies, but their failure modes differ. apt's resolver is conservative — it will hold back packages rather than break a working configuration, which is why "kept back" messages are common on Debian/Ubuntu. dnf and zypper both have richer resolvers that can describe several alternative ways to satisfy a request and ask you to choose. pacman is the strictest: a partial upgrade is officially unsupported, which is the reason -Syu exists as a single command.

Repositories and trust

Every package manager verifies the GPG signatures on packages and on the repository index before it trusts them. The trust roots ship with the distribution; adding a new repository (a PPA on Ubuntu, a COPR on Fedora, the AUR on Arch) typically means adding a new key as well. Pay attention to this step — a quietly-imported third-party key is one of the easier ways to get malware onto a Linux system.

Snapshots and transactions

Some distributions can take a filesystem snapshot before a package transaction and roll back if something goes wrong. openSUSE Tumbleweed and openSUSE Leap with Btrfs do this by default through Snapper. Fedora Silverblue and Kinoite take a different approach, layering rpm-ostree on top of dnf so that every system change is atomic. On Debian, Ubuntu and Arch, this isn't automatic but can be added with Timeshift or by using a Btrfs root and managing snapshots manually.

Cross-distribution packaging

In addition to the distribution's own package manager, two cross-distribution systems are widely supported:

• Flatpak — sandboxed applications, typically distributed through flathub.org. Useful when you want a recent version of an application that the distribution package lags behind.
• Snap — Canonical's packaging format, preinstalled on Ubuntu. Similar in goals to Flatpak, tied to a central store.

These are not replacements for the distribution package manager — you still need it for system libraries, the kernel, and command-line tools — but they coexist comfortably and are a fine way to install desktop applications.

Common mistakes

• Mixing apt and dpkg on Debian without good reason. When you can use apt install, do; it handles dependencies correctly. Reach for dpkg -i only when you have a stray .deb file with no repository.
• Running pacman -Sy <package> on Arch. This refreshes the repositories without upgrading them — a guaranteed way to install a package compiled against libraries newer than the ones currently installed. Always pair with -u: pacman -Syu <package>.
• Adding random PPAs or COPRs without reading what they contain. Third-party repositories are convenient, but they are trust-on-first-use and ship at upstream's pace. Stick to repositories from upstream projects you already trust.
• Force-removing packages with broken dependencies. Tempting in the moment, but it usually moves the problem somewhere else. Read the error message instead — most resolver failures describe an alternative that works.

Related reading

• Essential Linux commands — including the everyday package-manager commands.
• Open source software on Linux — categories of software and where to find them.
• Linux distributions — which package manager comes with which distribution.
• Linux security overview — how distributions publish and apply security updates.