What a Package Manager Actually Does

Chapter 1
Package Management Concepts
What a package manager actually does, package vs source installation, and how dependency resolution works under the hood

Every piece of software installed on Linux beyond what shipped with the OS has to get onto the system somehow — package managers are the tool that handles that, consistently and safely, across the entire system. This course covers APT (Debian/Raspbian — Philip's actual machines) and RPM-based tools (RedHat/Fedora) side by side, but this chapter starts with the concepts shared by both, and most other package managers too.

What a Package Manager Actually Does

📦 Installs software
Downloads a pre-built package and places its files in the correct system locations — binaries, libraries, config files, documentation — all in one coordinated operation.
🔗 Resolves dependencies
Automatically identifies and installs whatever else a package needs to actually function — covered in depth below.
📋 Tracks what's installed
Maintains a database of every installed package, its version, and exactly which files belong to it — the foundation of clean removal and upgrades.
⬆️ Handles updates
Checks for newer versions and applies them, ideally without breaking whatever already depends on the older version.
🗑️ Enables clean removal
Because it tracked every file a package installed, removal can delete exactly those files — not a guess, a precise, reversible record.

Package Install vs Source Install

📦
Installing a Package
A pre-built, pre-compiled bundle (a .deb or .rpm file) — software ready to run immediately, tracked by the package manager's database, dependency-checked automatically, trivially removable later.
🛠️
Building from Source
Downloading raw source code and compiling it yourself (./configure && make && make install) — full control over build options, but the package manager has no idea this software exists, no automatic dependency tracking, and no clean way to uninstall it later.
Software installed from source becomes genuinely invisible to your package manager
Nothing installed via make install shows up when checking installed packages, gets flagged for security updates, or can be removed with a simple uninstall command — it's just files copied onto the filesystem with no tracking at all. This is exactly why "compile it yourself" should be a last resort, reserved for software genuinely unavailable as a package, not a default habit.

Dependency Resolution — The Core Problem Package Managers Solve

Almost no piece of software is fully self-contained — it relies on shared libraries, other tools, specific versions of both. Installing something with unmet dependencies either fails outright or, worse, installs something broken that fails the moment it's actually run.

your-app libssl3 >=3.0 libc6 >=2.34 zlib1g
your-app declares exactly which other packages, and which minimum versions, it needs to actually run

How Resolution Actually Works

  1. Read the target package's declared dependencies — every package includes metadata listing exactly what it needs.
  2. Check what's already installed and at what version.
  3. Calculate the full set of packages needed — including dependencies of dependencies, recursively, until everything is satisfied.
  4. Present the full install/upgrade plan — most package managers show this list before actually proceeding, letting you review what's about to happen.
$ # A real apt example — note it lists everything that will actually be pulled in
$ sudo apt install nginx
The following additional packages will be installed:
libnginx-mod-http-geoip2 nginx-common nginx-core
0 upgraded, 4 newly installed, 0 to remove

Dependency Conflicts — When Resolution Can't Find a Clean Answer

Sometimes two packages require genuinely incompatible versions of the same shared dependency — package managers detect this and refuse to proceed with a silently broken install, instead reporting the conflict explicitly so it can be resolved deliberately (often by choosing one of the conflicting packages, or finding an alternative).

"Dependency hell" is a real, historical term for a real, mostly-solved problem
Before modern package managers with proper automated resolution became standard, manually tracking down and installing the correct version of every dependency by hand — and the cascading conflicts that followed — was genuinely painful enough to earn that specific nickname. Modern apt/dnf largely automate this away, which is exactly why this course exists: understanding the tool that quietly solves a problem that used to be a major source of real frustration.

The Two Families This Course Covers

  • Debian-based (APT) — Debian, Ubuntu, Raspbian/Raspberry Pi OS. Package format: .deb. Philip's actual Debian server and Raspberry Pi both live in this family — covered in depth across Chapters 2-4.
  • RedHat-based (RPM/dnf) — Fedora, RHEL, CentOS/Rocky/Alma. Package format: .rpm. Covered for comparison and general understanding in Chapters 5-7, even without day-to-day use on these specific systems.

Chapter 1 Quick Reference

  • A package manager installs, tracks, updates, and cleanly removes software — maintaining a real database of what's installed and which files belong to it
  • Package install — pre-built, tracked, dependency-checked, cleanly removable
  • Source install — full control, but completely invisible to the package manager — no tracking, no clean removal
  • Dependency resolution — reads declared requirements, checks what's installed, calculates the full set needed, presents the plan before acting
  • Dependency conflicts are reported explicitly rather than silently producing a broken install
  • This course covers: APT/Debian family (Ch2-4, Philip's actual machines) and RPM/RedHat family (Ch5-7, for comparison)
  • Next chapter: APT in depth — apt vs apt-get vs dpkg, installing/removing/upgrading