15 minpackagesaptyumdnf

Package Management

Learn package management concepts for DevOps interviews

05 — Package Management

How software gets installed, updated, and removed. Interviewers check that you understand the two families (Debian/apt and RHEL/dnf), the low-level vs high-level tools, repos, dependency resolution, and how to pin/hold versions in production.

1. The two big families

	Debian family (Ubuntu, Debian)	RHEL family (RHEL, Rocky, Fedora, Amazon Linux)
Package format	`.deb`	`.rpm`
Low-level tool	`dpkg`	`rpm`
High-level tool (resolves deps + repos)	`apt` (`apt-get`)	`dnf` (older: `yum`)
Repo config	`/etc/apt/sources.list`, `/etc/apt/sources.list.d/`	`/etc/yum.repos.d/*.repo`
Package DB	`/var/lib/dpkg`	`/var/lib/rpm`

🎯 Interview signal: “dpkg/rpm install a single local package but don’t resolve dependencies; apt/dnf sit on top, talk to repositories, and pull in dependencies automatically.” That low-level vs high-level distinction is the core concept.

2. Debian family: apt / dpkg

sudo apt update                     # refresh the package index from repos (NOT an upgrade!)
sudo apt upgrade                    # install available updates
sudo apt install nginx              # install + dependencies
sudo apt remove nginx               # remove package (keep config)
sudo apt purge nginx                # remove package AND config
sudo apt autoremove                 # remove orphaned dependencies
apt search nginx                    # find packages
apt show nginx                      # package details
apt list --installed                # what's installed
dpkg -l | grep nginx                # query the dpkg database
dpkg -L nginx                       # list files a package installed
dpkg -S /usr/sbin/nginx             # which package owns a file?
sudo dpkg -i pkg.deb                # install a local .deb (no dep resolution)
sudo apt install ./pkg.deb          # install a local .deb WITH dep resolution

⚠️ apt update ≠ apt upgrade. update only refreshes the index of what’s available; upgrade actually installs newer versions. A very common beginner mix-up interviewers catch.

3. RHEL family: dnf / yum / rpm

sudo dnf check-update               # what updates are available
sudo dnf upgrade                    # apply updates
sudo dnf install nginx              # install + dependencies
sudo dnf remove nginx               # remove
sudo dnf search nginx               # find
dnf info nginx                      # details
dnf repolist                        # enabled repos
rpm -qa | grep nginx                # all installed packages
rpm -ql nginx                       # files installed by a package
rpm -qf /usr/sbin/nginx             # which package owns a file
sudo rpm -ivh pkg.rpm               # install a local rpm (no dep resolution)
sudo dnf install ./pkg.rpm          # local rpm WITH dependency resolution
dnf history                         # transaction history (and you can UNDO)
sudo dnf history undo <id>          # roll back a transaction ← powerful

🎯 Interview signal: “dnf history undo can roll back a package transaction — great for recovering from a bad update.” apt has no built-in equivalent (you reinstall specific versions).

4. Repositories & trust

A repository is a server hosting packages + a signed metadata index.
Packages are GPG-signed; the package manager verifies signatures against imported keys, so you don’t install tampered software.

Debian: add a repo + key

# modern approach: keyring file + signed-by
curl -fsSL https://example.com/key.gpg | sudo gpg --dearmor -o /etc/apt/keyrings/example.gpg
echo "deb [signed-by=/etc/apt/keyrings/example.gpg] https://example.com/apt stable main" \
  | sudo tee /etc/apt/sources.list.d/example.list
sudo apt update

RHEL: a .repo file

# /etc/yum.repos.d/example.repo
[example]
name=Example Repo
baseurl=https://example.com/rpm/
enabled=1
gpgcheck=1
gpgkey=https://example.com/RPM-GPG-KEY-example

⚠️ Disabling GPG checks (gpgcheck=0 / --allow-unauthenticated) to “make it work” is a security red flag — you lose integrity verification. Interviewers may probe this.

5. Dependency resolution (the concept)

When you install a package, the high-level tool:

Reads the package’s declared dependencies.
Consults repo metadata to find versions that satisfy them.
Computes a transaction (install/upgrade/remove set) that keeps the system consistent.
Downloads, verifies signatures, and installs in the right order (pre/post scripts run).

⚠️ Dependency hell: conflicting version requirements between packages. Modern apt/dnf handle most cases; when they can’t, you’ll see held-back packages or conflicts. Fixes: update the index, allow the newer dependency, or use the vendor’s repo. On RHEL, modules/streams (dnf module) pin a major version of a stack (e.g., Node 18 vs 20).

6. Pinning / holding versions (production must-know)

You often want to freeze a package at a known-good version so an update doesn’t break prod.

Debian:

sudo apt-mark hold nginx        # never auto-upgrade nginx
sudo apt-mark unhold nginx
apt-mark showhold

RHEL:

sudo dnf install python3-dnf-plugin-versionlock
sudo dnf versionlock add nginx  # lock the current version
sudo dnf versionlock list

🎯 Interview signal: “In production I hold/versionlock critical packages (kernel, DB, runtime) so an unattended upgrade can’t silently change a version, and I roll versions forward deliberately through change control.”

⚠️ Unattended/automatic upgrades (unattended-upgrades on Debian, dnf-automatic on RHEL) are great for security patches but can restart services or change behavior — scope them to security updates and hold the risky packages.

7. Practical extras

# Debian: what will an upgrade change / why is a package held back?
apt list --upgradable
apt-cache policy nginx        # candidate vs installed version, which repo it comes from

# Clean caches to reclaim space (file 07 disk-full incidents)
sudo apt clean && sudo apt autoremove
sudo dnf clean all

# Reinstall a package whose files got corrupted/deleted
sudo apt install --reinstall nginx
sudo dnf reinstall nginx

Language/app package managers (pip, npm, gem) are separate from the OS package manager — and mixing sudo pip install with system Python is an anti-pattern (use virtualenvs). Interviewers may check you don’t confuse OS packages with app packages.

Interview Questions

Q1. What’s the difference between dpkg/rpm and apt/dnf?

dpkg and rpm are low-level tools that install/query a single local package but don’t resolve dependencies or talk to repositories. apt and dnf are high-level front-ends that use repositories, resolve and download dependencies automatically, verify signatures, and compute a consistent transaction. In practice you use apt/dnf for everything except installing a standalone local package file.

Q2. What does apt update do vs apt upgrade?

apt update refreshes the local index of available packages/versions from the configured repositories — it installs nothing. apt upgrade actually installs newer versions of installed packages based on that index. You run update first, then upgrade.

Q3. How do you find which package owns a file, and which files a package installed?

Debian: dpkg -S /path/to/file for the owning package, dpkg -L pkg for its files. RHEL: rpm -qf /path/to/file and rpm -ql pkg. Useful when a config or binary appears and you need to know where it came from.

Q4. How does dependency resolution work and what is dependency hell?

The package manager reads a package’s declared dependencies, finds satisfying versions in repo metadata, and computes an install/upgrade/remove transaction that keeps the system consistent, then installs in order. Dependency hell is when packages require conflicting versions of a shared dependency so no consistent set exists. Modern apt/dnf resolve most cases; otherwise you use vendor repos, allow newer deps, or dnf module streams to pin a stack’s major version.

Q5. How do you prevent a critical package from being upgraded in production?

Hold it: apt-mark hold <pkg> on Debian or dnf versionlock add <pkg> on RHEL. That freezes it at the current version so automatic/unattended upgrades can’t change it, and you roll it forward deliberately through change control. I’d typically hold the kernel, database, and language runtimes.

Q6. How do you verify packages are authentic?

Repositories serve GPG-signed metadata and packages; the package manager verifies signatures against imported keys before installing (gpgcheck=1 on RHEL, signed-by keyrings on Debian). Disabling those checks removes integrity/authenticity guarantees and is a security risk.

Q7. A bad update broke a box. How do you recover on RHEL vs Debian?

On RHEL, dnf history shows transactions and dnf history undo <id> rolls the transaction back. On Debian there’s no built-in undo, so you reinstall the previous known-good versions explicitly (apt install pkg=version) — which is why holding critical versions and testing in staging matters. Snapshots/backups are the safety net either way.

Q8. (Senior) How do you handle security patching at fleet scale without breaking services?

Automate security-only updates (unattended-upgrades scoped to the security pocket, or dnf-automatic in security mode), version-lock the risky packages (kernel/DB/runtime), stage updates in a canary group before fleet-wide rollout, and orchestrate reboots (for kernel updates) through a maintenance window with health checks and the ability to roll back. Config management (Ansible) or an internal mirror gives consistent, auditable versions across hosts.

Next: 06 — Networking — the other half of most production incidents.