<aside> 📦
Module 9 — Package Management
Where do programs come from? Not by copying binaries around by hand — by a package manager that installs software with its dependencies, tracks every file it owns, updates it, and removes it cleanly. This module teaches the Debian family (apt/dpkg, what Ubuntu servers run) in depth and the Red Hat family (dnf/rpm) by faithful parallel, so you can work on either fleet an interviewer hands you.
Legend used throughout: 🧠 concept → 🧩 analogy → 🧪 exercise → ✅ expected result (hidden) → 🎯 interview questions (hidden)
</aside>
<aside> 🚦
Before you start
You need Modules Module 1 — What Linux Is–Module 8 — Processes — especially sudo and the root model (Module 4: installing changes the whole system, so it needs root), the filesystem layout (Module 2: packages put files in standard places), and pipes/grep (Modules 5–7: you will filter package listings constantly). Tools: an Ubuntu 24.04 machine with sudo. Installing requires working network access to the distro's servers; a few exercises install a tiny, harmless package (tree) and remove it again.
</aside>
<aside> ℹ️
This page uses Mermaid diagram blocks. Notion shows them as code by default — click the block and set it to Preview to see the diagram. This reminder appears once per page.
</aside>
<aside> 📖
Official docs: apt(8) — Ubuntu manpage · Ubuntu package management docs
</aside>
🧠 Almost no program stands alone. A web server needs an SSL library; that library needs a compression library; that needs the C library. Installing software by hand means chasing this chain yourself — the infamous "dependency hell" of the 1990s, where installing one thing meant hunting down twelve others in the right versions. A package manager ends it: you name what you want, and it computes the full dependency tree, fetches every piece from a trusted repository, installs them in the right order, and records exactly what it did so it can be undone. A package is one unit of that system: a compressed archive of files plus metadata — its version, its dependencies, and where its files belong.
<aside> 🧩
Real-world analogy — furniture delivery, assembled
Buying a bookshelf that "requires" brackets, screws, and wall anchors, you do not drive to four shops. The store bundles everything, delivers it together, and keeps a record of your order for returns. The package manager is that store: order the bookshelf, receive the whole bill of materials, keep the receipt.
Where the analogy stops working. A furniture store ships you duplicate screws with every order. A package manager is smarter: if the C library is already installed, it is shared, not re-delivered — one copy on disk serves every program that needs it. That sharing is the whole point, and also the whole risk (A2's counter-intuition): removing "your" screws can collapse someone else's shelf.
</aside>
🧪 Exercise A1.1 — See a dependency chain
apt-cache depends tree # what does the 'tree' package require?
apt-cache depends bash | head -12 # and something more central
<aside> 📖
Official docs: dpkg(1)
</aside>
🧠 Installing is not "copying a binary somewhere". The package manager unpacks the files into their standard locations (Module 2's FHS — binaries to /usr/bin, configs to /etc, docs to /usr/share) and writes an entry into a database recording the package's name, version, dependency links, and — crucially — the exact list of files it placed. That database is what makes clean removal, integrity checking, and "which package owns this file?" possible. On Debian systems it lives under /var/lib/dpkg/; dpkg is the low-level tool that reads and writes it.
<aside> 🧠
Counter-intuitive: never delete an installed program's files with rm. The files vanish, but the database still says the package is installed — so it won't reinstall cleanly, its dependencies still count it as present, and upgrades trip over the discrepancy. The package database and the disk have silently disagreed, and every tool trusts the database. Removal must go through the package manager (apt remove), which deletes the files and updates the record. Manually rm-ing packaged files is the "haunted system" generator.
</aside>
<aside> 🧩
Real-world analogy — the library's catalogue
A library is its books and its catalogue. Shelve a book without cataloguing it and nobody can find it; remove a book but leave its card and the catalogue lies to every patron. The package database is the catalogue; the files are the books; they must change together.
Where the analogy stops working. A librarian notices a missing book when reshelving. The package system has no such background audit by default — a hand-deleted file goes unnoticed until an upgrade or a dpkg -V integrity check stumbles on the gap, often months later, often mid-incident. The catalogue trusts itself completely, which is exactly why you must never let it drift from reality.
</aside>
🧪 Exercise A2.1 — Interrogate the database
dpkg -l | head -6 # the database header, then installed packages
dpkg -l | wc -l # roughly how many packages make up this system?
dpkg -s bash | head -8 # one package's full record