Linux Package Managers: apt vs yum

What and Why

A Linux package manager installs software, tracks files it owns, resolves dependencies, and applies updates. The two dominant families are Debian-based (Ubuntu, Debian) using .deb files managed by apt on top of dpkg, and Red Hat-based (RHEL, Fedora, Rocky, Alma) using .rpm files managed by yum or its successor dnf on top of rpm.

You need to know both because base images differ across cloud providers, Docker images, and customer environments. Choosing the wrong command at the wrong moment is how production servers end up unbootable.

Mental Model

Both managers do the same four things:

1. Read a list of configured repositories.
2. Download metadata describing available packages and versions.
3. Resolve a dependency graph for what you asked to install.
4. Download, verify, and unpack files, then run scripts for setup.

The differences are in defaults: package format, repo config locations, signing, and how aggressively each tool removes orphaned dependencies.

Hands-on Example

Install nginx on both, then add a third-party repo.

# Debian/Ubuntu
sudo apt update
sudo apt install -y nginx
apt list --installed | grep nginx
sudo apt remove nginx          # keep config files
sudo apt purge nginx           # remove config too
sudo apt autoremove            # drop orphaned deps

# RHEL/Fedora
sudo dnf install -y nginx
dnf list installed nginx
sudo dnf remove nginx          # also removes orphaned deps by default
sudo dnf autoremove            # explicit cleanup pass

Adding HashiCorp’s repo on Ubuntu:

curl -fsSL https://apt.releases.hashicorp.com/gpg \
  | sudo gpg --dearmor -o /etc/apt/keyrings/hashicorp.gpg
echo "deb [signed-by=/etc/apt/keyrings/hashicorp.gpg] \
  https://apt.releases.hashicorp.com $(lsb_release -cs) main" \
  | sudo tee /etc/apt/sources.list.d/hashicorp.list
sudo apt update && sudo apt install terraform

On RHEL:

sudo dnf config-manager --add-repo \
  https://rpm.releases.hashicorp.com/RHEL/hashicorp.repo
sudo dnf install terraform

apt install nginx
 |
 v
sources.list -> fetch Release + Packages -> resolve deps
 |
 v
.deb downloaded -> dpkg unpacks -> postinst runs

dnf install nginx
 |
 v
*.repo -> fetch repodata/repomd.xml -> resolve deps
 |
 v
.rpm downloaded -> rpm unpacks -> %post scriptlet runs

Common Pitfalls

• Skipping apt update: stale metadata makes apt try to fetch versions that no longer exist on the mirror, producing confusing 404s.
• Mixing repos: pulling packages from Debian unstable into Debian stable, or EPEL packages that conflict with RHEL versions, leads to broken dependency chains.
• Force installing with --force-yes or --nobest: these bypass safety checks and frequently break the next upgrade.
• Holding partial upgrades: running apt upgrade when apt full-upgrade is needed, or excluding kernel updates, can leave a system in an inconsistent state.
• Ignoring GPG warnings: a repo whose key is not trusted is a supply chain problem, not a nuisance message.

Practical Tips

• Use apt-mark hold <pkg> or dnf versionlock <pkg> to pin packages you cannot afford to upgrade unexpectedly.
• Inspect what a package owns with dpkg -L <pkg> or rpm -ql <pkg>.
• Find which package owns a file with dpkg -S /path or rpm -qf /path.
• Run apt-get dist-upgrade --simulate or dnf upgrade --assumeno to preview changes before applying them.
• On servers, prefer unattended-upgrades (Debian) or dnf-automatic for security patches, scoped to security only.

Wrap-up

apt and yum/dnf solve the same problem with slightly different ergonomics. Learn the equivalents, respect GPG verification, and never trust a --force flag in a postmortem story. Once the mental model clicks, switching between Ubuntu and RHEL boxes is a matter of muscle memory, not relearning.