How software reaches a Linux system, stays patched, and gets removed cleanly — from signed repositories down to the dependency resolver.
5 topics
A package manager is the part of the operating system most administrators touch every day and think about least. It turns "install nginx" into a sequence of downloads, signature checks, dependency resolution, file extraction, and post-install scripts — and it keeps a database so the same files can later be upgraded or removed without leaving orphans behind. Get it wrong and you end up with broken dependency chains, untracked files under /usr/local, or a server that has quietly stopped receiving security updates.
This chapter works from the model down to the tools. It starts with how repositories, metadata, and signing keys fit together, then covers the two dominant native stacks — Debian's apt/dpkg and Red Hat's dnf/rpm — followed by the older path of compiling from source when no package exists, and the newer cross-distribution formats that bundle their own dependencies. Debian and Ubuntu lead throughout, with Red Hat equivalents called out where the two diverge.
Two layers of package management
apt — the resolver
Talks to signed repositories, downloads packages, and resolves the full dependency tree. This is the layer you use every day: update, install, upgrade, purge.
dpkg — the installer
Installs a single .deb and records what files it owns, with no dependency resolution. You drop to it to query (dpkg -S, dpkg -L) or force, then let apt repair.
the repository
A signed, indexed server of packages. Trust comes from its GPG key; everything apt installs is verified against it, which is why curl-pipe-to-shell side-steps the whole model.