Linux Package Managers: apt, yum and dnf

How it works

A package manager works in two layers. The first is the local index, a cached snapshot of what packages exist in your configured repositories and which versions are available. The second is the package database, a record of what is actually installed on the machine right now.

When you ask the package manager to install something, it checks the index for a match, resolves the full dependency tree, downloads the relevant packages from the repository and records the installation in its database. When you remove something, it marks it gone in the database and optionally removes the files from disk. None of this requires internet access for the resolution step, only for the download.

apt

apt is the primary package management tool on Debian and Ubuntu. It builds on top of a lower-level library called dpkg, which handles the actual installation and removal of .deb packages. You will occasionally see references to apt-get, the older command-line interface for the same underlying system. The two are largely interchangeable in daily use, but apt has cleaner output and is preferred for interactive work.

The distinction between apt remove and apt purgematters more than it first appears. Leaving configuration files behind with remove is useful when you might reinstall the same package and want to pick up from the same state. Using purge makes sense when you are done with a service entirely and want a clean slate.

dnf and yum

dnf is the package manager on Fedora, RHEL 8 and later, CentOS Stream and related distributions. It works with .rpm packages and handles dependency resolution, repository management and transaction history. yum was its predecessor and is still the primary tool on older RHEL 7 and CentOS 7 systems.

The practical difference for most day-to-day tasks is minimal. If you are on a system with yum, substituting yum for dnf in most commands will work. Where dnf genuinely improves on yum is in dependency resolution speed and the transaction history system, which lets you inspect and roll back past operations.

Repositories

Every package the manager installs comes from a repository. A repository is just a structured collection of packages hosted somewhere accessible, usually a web server, along with metadata that describes what is available. The package manager reads from configuration files to know where to look.

Third-party software often comes with instructions to add a repository before installing. On Debian-based systems this typically means adding a signed repository key with gpg and dropping a source file into /etc/apt/sources.list.d/. On Red Hat-based systems it usually means installing an RPM that drops a .repo file into /etc/yum.repos.d/. Both approaches mean the package manager can keep the software updated through normal upgrade operations.

Pinning versions

Sometimes you need a package to stay at a specific version and not move during a system upgrade. A library that a critical application depends on, a kernel version known to be stable for a particular workload, a database package that requires careful manual migration before it can be upgraded.

Inspecting packages

The package database is queryable. When something breaks after an update, or when you need to know which package owns a particular file, the tools below let you answer those questions without guessing.

Security updates

Both package management families distinguish between security updates and general updates. On production systems it is common to apply only security patches automatically rather than pulling in every new feature release.

On Debian and Ubuntu, the unattended-upgrades package handles automated security patching. It reads from a configuration file that specifies which update categories to apply automatically. Enabling it on production servers is common practice because keeping up with security patches manually is unreliable over time.