System Package Managers

In one line

apt (Debian/Ubuntu) and yum/dnf (RHEL/CentOS/Fedora) install, update, and remove system-level software — knowing the standard update-then-install workflow and how to add trusted third-party sources covers the vast majority of real needs.

0/3 · 0%

Think of it like this

A package manager is like an app store for the operating system itself — instead of hunting down a piece of software's website, downloading an installer, and manually tracking whether it's up to date, you ask the package manager by name and it handles fetching, installing, and later updating it, along with anything else it depends on.

Key ideas

01
apt is the package manager on Debian/Ubuntu systems — this course's reference distro, as noted back in Phase 0. sudo apt update refreshes the LOCAL LIST of what packages and versions are available (it does not install or upgrade anything itself) — this should almost always be run before install, since installing from a stale package list can fail or fetch an outdated version.
02
sudo apt install <package> installs new software, automatically pulling in any DEPENDENCIES it needs along the way — this automatic dependency resolution is one of a package manager's biggest advantages over manually downloading and installing software yourself, since manually tracking every transitive dependency by hand is genuinely impractical.
03
sudo apt upgrade updates every currently-installed package to its latest available version (based on the list update just refreshed). sudo apt remove <package> uninstalls it; sudo apt autoremove cleans up dependencies that were only installed FOR a now-removed package and are no longer needed by anything else.
04
RHEL-family distributions (CentOS, Fedora, Rocky Linux, Amazon Linux) use yum or its modern replacement dnf instead — the commands are nearly identical in spirit (sudo dnf install <package>, sudo dnf update), just a different underlying tool and package format (.rpm instead of .deb). Knowing apt well makes picking up yum/dnf quick, since the mental model transfers directly.
05
apt search <term> looks for packages matching a keyword when you don't know the exact package name, and apt show <package> displays details about a specific one (description, version, dependencies) before you commit to installing it — genuinely useful for confirming you've found the right package before installing something unfamiliar.

In your stack

→
Installing a JDK is a classic real example: sudo apt update && sudo apt install openjdk-21-jdk pulls in a complete, correctly-configured Java installation with one command — no manually downloading an installer or setting environment variables like JAVA_HOME by hand, since the package handles that setup itself.

Code & diagrams

apt-basics.shmarkdown

The standard apt workflow — always update before installing.

# Refresh the package list FIRST (doesn't install/upgrade anything itself)
sudo apt update

# Search for a package if you don't know the exact name
apt search "postgresql"

# See details about a specific package before installing
apt show postgresql

# Install it (dependencies are resolved automatically)
sudo apt install postgresql

# Upgrade everything currently installed
sudo apt upgrade

# Remove a package you no longer need
sudo apt remove postgresql

# Clean up now-orphaned dependencies
sudo apt autoremove

# See exactly which version of a package is installed
apt list --installed | grep postgresql

Explain it without notes

Why should you run apt update before apt install, given that update itself doesn't install anything?

What real problem does a package manager's automatic dependency resolution actually solve, in concrete terms?

Practice

Search for a package you use often (like git or curl) with apt search, view its details with apt show, then confirm whether it's already installed with apt list --installed.

Install a small, harmless package (like tree, a simple directory-listing tool), use it once, then remove it with apt remove and confirm autoremove doesn't flag any leftover dependencies (since tree typically has none).

Trade-offs

↔
System package managers are reliable and centrally managed, but their repositories often lag behind a project's newest upstream release — for software that needs to be genuinely current (a specific Node.js version, a bleeding-edge database version), a language-specific version manager or the vendor's own repository is usually the better source, while apt remains the right choice for stable, foundational system tools.

Done when you can

I know to run apt update before apt install, and why.
I can search for, inspect, install, and remove a package using apt.
I understand that yum/dnf serve the same role as apt on RHEL-family distributions.

Command Palette