Linux Package Managers Compared: apt vs yum vs dnf vs pacman

Table of Contents

Why Package Managers Matter More Than You Think

SSH into a fresh Linux server and the first tool you’ll reach for is a package manager. It installs software, resolves dependencies, and keeps your system current. The catch for newcomers: different distros ship with different package managers, and the commands don’t carry over.

If you’ve ever typed apt install nginx on a CentOS machine and wondered why it failed, you’ve already hit this wall. This guide covers the four most common package managers — apt, yum, dnf, and pacman — so you know exactly what to reach for on any distro you land on.

Which Package Manager Goes With Which Distro?

apt — Debian, Ubuntu, Linux Mint, Pop!_OS
yum — CentOS 7, RHEL 7, older Fedora
dnf — Fedora, CentOS 8+, RHEL 8+, AlmaLinux, Rocky Linux
pacman — Arch Linux, Manjaro, EndeavourOS

The underlying package formats differ too: Debian-based distros use .deb files, Red Hat-based distros use .rpm files, and Arch uses .pkg.tar.zst. The package manager abstracts all of that — you run a command and it handles the rest.

Installation: Getting Packages Onto Your System

The same operations look different on each distro. Once you spot the pattern, switching between systems gets a lot less painful.

Installing a Package

# apt (Debian/Ubuntu)
sudo apt update && sudo apt install nginx

# yum (CentOS 7 / RHEL 7)
sudo yum install nginx

# dnf (Fedora / CentOS 8+ / AlmaLinux)
sudo dnf install nginx

# pacman (Arch Linux)
sudo pacman -Syu nginx

One habit worth building with apt: always run apt update before installing. Skip it and your package index could be stale — you might install an outdated version, or hit a dependency error that doesn’t obviously point to the cause.

dnf handles that step automatically. It refreshes metadata before installing, which is the main reason most people prefer it over yum today.

Note the pacman command above uses -Syu, not just -Sy. On Arch, always do a full system upgrade before installing new packages. Refreshing the database without upgrading creates a partial upgrade situation that can break things in non-obvious ways.

Removing a Package

# apt
sudo apt remove nginx
# To also remove leftover config files:
sudo apt purge nginx

# yum / dnf
sudo yum remove nginx
sudo dnf remove nginx

# pacman
sudo pacman -R nginx
# Remove with unused dependencies:
sudo pacman -Rs nginx

The apt purge vs apt remove difference trips a lot of people up. remove keeps config files on disk; purge wipes them completely. On a production Ubuntu 22.04 server, I switched to defaulting purge when removing old services. Config files from removed packages accumulate quietly — after several months of normal maintenance, the orphaned configs add up faster than you’d expect.

Upgrading All Packages

# apt
sudo apt update && sudo apt upgrade
# Full upgrade (handles dependency changes):
sudo apt full-upgrade

# yum
sudo yum update

# dnf
sudo dnf upgrade

# pacman
sudo pacman -Syu

Arch’s pacman -Syu does a full rolling-release system upgrade. Run it regularly — letting an Arch system drift out of sync with the repos is asking for trouble. Partial upgrades can break things in ways that are hard to trace.

Ubuntu and RHEL-based systems are more conservative. Upgrades are staged and predictable, which makes them safer for servers you can’t afford to babysit.

Configuration: Tweaking How Your Package Manager Behaves

The defaults cover most cases, but knowing where config files live is useful when things break — or when you need to pull in packages from a third-party repository.

apt Configuration (Debian/Ubuntu)

Repositories are defined in /etc/apt/sources.list and individual files under /etc/apt/sources.list.d/. Adding a PPA is the most common customization on Ubuntu:

# Add a PPA
sudo add-apt-repository ppa:deadsnakes/python3.12
sudo apt update

# View all configured repos
cat /etc/apt/sources.list
ls /etc/apt/sources.list.d/

Need to freeze a package at its current version and keep it from upgrading automatically? Use apt-mark hold:

# Hold a package at its current version
sudo apt-mark hold nginx

# Unhold it later
sudo apt-mark unhold nginx

dnf Configuration (Fedora/RHEL/AlmaLinux)

The main config file sits at /etc/dnf/dnf.conf. Repositories live in /etc/yum.repos.d/ as .repo files. A few options worth enabling on a fresh install:

# /etc/dnf/dnf.conf — useful options
[main]
fastestmirror=True
keepcache=True
max_parallel_downloads=10

Adding EPEL (Extra Packages for Enterprise Linux) is almost always the first thing I do on a new AlmaLinux or Rocky Linux server — it adds thousands of packages that aren’t in the base repos:

# On AlmaLinux / Rocky Linux / RHEL
sudo dnf install epel-release
sudo dnf update

pacman Configuration (Arch Linux)

Arch stores its config at /etc/pacman.conf. Common tweaks include enabling the multilib repo for 32-bit software, or setting up an AUR helper. yay is the most widely used:

# Install yay (AUR helper) — do this as a regular user, not root
git clone https://aur.archlinux.org/yay.git
cd yay && makepkg -si

# Then use yay just like pacman, but for AUR packages too
yay -S google-chrome

The AUR is Arch’s biggest draw for desktop users. It covers an enormous range of community-maintained packages — software you simply won’t find in the official repos of Debian or Fedora.

Verification & Monitoring: Keeping Your System Clean and Auditable

Getting packages installed takes seconds. The ongoing challenge is knowing what’s actually on the system, catching orphaned packages before they pile up, and verifying that nothing has been quietly corrupted.

Searching for and Inspecting Packages

# Search for a package by name
apt search nginx
dnf search nginx
yum search nginx
pacman -Ss nginx

# Show detailed info about a package
apt show nginx
dnf info nginx
pacman -Si nginx

# List all installed packages
dpkg --get-selections         # Debian/Ubuntu
rpm -qa                       # RHEL/CentOS/Fedora
pacman -Q                     # Arch

Finding and Removing Orphaned Packages

Remove a piece of software and its pulled-in dependencies don’t always go with it. Those leftover packages waste space and occasionally cause confusion during future upgrades.

# apt — remove packages installed as dependencies that are no longer needed
sudo apt autoremove

# dnf
sudo dnf autoremove

# pacman — list orphans
pacman -Qdt
# Remove them
sudo pacman -Rns $(pacman -Qtdq)

On my production Ubuntu 22.04 server, a single apt autoremove after a major version cleanup reclaimed almost 400MB of disk space. On a VPS where storage costs money, that kind of routine maintenance pays for itself quickly.

Checking Package Integrity

# Verify installed RPM packages (yum/dnf systems)
rpm -Va
# Check a specific package
rpm -V nginx

# On Debian/Ubuntu, reinstall to restore corrupted files
sudo apt --reinstall install nginx

# On Arch, verify package files
pacman -Qk nginx

Viewing Package History and Logs

Something breaks and you need to know what changed. Package logs are the first place to look.

# apt history
cat /var/log/apt/history.log

# dnf transaction history
dnf history
dnf history info 5       # Details on transaction #5
dnf history undo 5       # Roll back that transaction

# pacman log
cat /var/log/pacman.log | tail -50

dnf history undo is genuinely underrated. A package update breaks something in your stack? Roll back the exact transaction — no need to manually track down what version you had before. I’ve used this twice to recover from a broken PHP upgrade on a CentOS 8 box. Zero downtime both times.

Quick Reference Cheat Sheet

Task	apt	dnf / yum	pacman
Update index	apt update	dnf check-update	pacman -Sy
Install	apt install pkg	dnf install pkg	pacman -S pkg
Remove	apt remove pkg	dnf remove pkg	pacman -R pkg
Upgrade all	apt upgrade	dnf upgrade	pacman -Syu
Search	apt search pkg	dnf search pkg	pacman -Ss pkg
Package info	apt show pkg	dnf info pkg	pacman -Si pkg
Remove orphans	apt autoremove	dnf autoremove	pacman -Rns $(pacman -Qtdq)
View history	/var/log/apt/history.log	dnf history	/var/log/pacman.log

Which One Should You Actually Use?

You don’t really choose — the distro decides. But each tool has a distinct personality:

apt is stable and predictable. Exactly what you want on servers where surprises are bad.
dnf has the best built-in transaction history and rollback. My go-to on enterprise Linux.
yum is effectively retired. If you’re still running a system that uses it, plan a migration when you get the chance.
pacman is fast, and the AUR makes it fantastic for desktop use. Rolling releases mean you need to stay current — not ideal for low-maintenance servers.

Once the commands become muscle memory, switching between distros stops feeling like starting over. The concepts are identical across all four — repos, packages, dependencies, cleanup. Only the syntax changes.