Package Managers

What is it? #

A package manager installs software along with its dependencies, from repositories the distribution maintains.

It handles the parts that make manual installation miserable: dependency resolution, upgrades, security patches and clean removal.

apt is the Debian and Ubuntu tool; dnf and yum cover Red Hat, Rocky and Amazon Linux. The commands differ, the concepts do not.

The two habits that matter on a server are updating the package list before installing, and applying security updates regularly rather than never.

Think of it like this #

An app store for the operating system. You ask for one program and it brings everything that program needs, keeps track of what is installed, and tells you when updates are available.

Downloading and compiling things by hand is the equivalent of installing software from an unlabelled disc found in a drawer.

Simple example #

You are setting up a new server. You need to update the package list, install Nginx and PostgreSQL, add a third-party repository for a newer language runtime, and set up automatic security updates.

Code #

# Debian / Ubuntu
sudo apt update                       # refresh the package list — always first
sudo apt upgrade                      # upgrade installed packages
sudo apt install nginx postgresql
sudo apt remove nginx                 # remove the package
sudo apt purge nginx                  # remove it and its configuration
sudo apt autoremove                   # remove orphaned dependencies

apt search redis                      # find a package
apt show nginx                        # version, size, dependencies
apt list --installed | grep python
dpkg -L nginx                         # which files did this package install?
dpkg -S /etc/nginx/nginx.conf         # which package owns this file?

# RHEL / Rocky / Amazon Linux
sudo dnf check-update
sudo dnf upgrade
sudo dnf install nginx postgresql-server
sudo dnf remove nginx
dnf info nginx
rpm -qa | grep python                 # installed packages
rpm -qf /etc/nginx/nginx.conf         # which package owns this file?

# Adding a third-party repository, the modern way
curl -fsSL https://example.com/key.gpg \
  | sudo gpg --dearmor -o /usr/share/keyrings/example.gpg

echo "deb [signed-by=/usr/share/keyrings/example.gpg] https://example.com/apt stable main" \
  | sudo tee /etc/apt/sources.list.d/example.list

sudo apt update && sudo apt install example-package
# The key verifies that packages genuinely come from that publisher.

# Security updates without babysitting (Ubuntu/Debian)
sudo apt install unattended-upgrades
sudo dpkg-reconfigure --priority=low unattended-upgrades
# Applies security patches automatically. Check whether a reboot is pending:
cat /var/run/reboot-required 2>/dev/null

# Hold a package at its current version
sudo apt-mark hold postgresql-16
sudo apt-mark unhold postgresql-16

How it works #

apt update refreshes the local list of available packages and versions. It installs nothing. Skipping it means installing from a stale list, which is why "package not found" is usually fixed by running it first.

apt upgrade installs newer versions of what you already have. apt full-upgrade will also remove packages when needed to complete an upgrade, which is more invasive.

remove leaves configuration behind, which is useful if you plan to reinstall. purge removes it too. Knowing the difference avoids the surprise of reinstalling a service and finding your old configuration still in place.

dpkg -S answers "which package owns this file", which is genuinely useful when investigating an unfamiliar server.

The third-party repository block shows the current approach: store the signing key in its own keyring file and reference it from the source entry. The key is what guarantees the packages come from the publisher and have not been tampered with. Adding a repository without a key, or piping an install script from the internet into a shell, is trusting a lot.

unattended-upgrades applies security patches automatically. Some updates need a reboot to take effect — kernel updates in particular — and the reboot-required file is how you know.

Holding a package pins it, which is how you prevent an automatic upgrade of a database or runtime that you want to control manually.

Real-world use #

Unpatched packages are one of the most common ways servers get compromised, and the vulnerabilities used are usually months old with patches available. Automatic security updates are a large improvement for very little effort.

The tension is stability. Automatic updates can restart services, and a kernel update needs a reboot. The usual compromise is automatic security-only updates, with reboots scheduled during a maintenance window.

Language runtimes are often too old in distribution repositories. Adding the official third-party repository is the standard solution, and pinning the version keeps upgrades deliberate.

Containers change the picture: you update the base image and rebuild rather than patching a running container, which the Docker track covers.

Keeping a record of what was installed matters. A configuration management tool, or at minimum a documented setup script, means a server can be rebuilt rather than hand-restored.

Common mistakes #

• Installing without running apt update first and getting a stale or missing package.
• Never applying security updates, leaving known vulnerabilities open for months.
• Adding third-party repositories without verifying the signing key.
• Piping an install script from the internet straight into a shell without reading it.
• Ignoring /var/run/reboot-required, so kernel patches never take effect.

Practice #

On a test machine, update the package list, install a small package, inspect which files it installed, then purge it. Then enable unattended security upgrades and check whether a reboot is currently required.