Package Managers, Compared Directly

Comparative Linux Distributions

Chapter 6 · Package Managers, Compared Directly

Chapters 2 through 5 each introduced one package manager on its own terms. This chapter puts all four side by side, doing the exact same real tasks — and covers a real dependency-resolution policy difference worth knowing before it causes a genuinely broken system.

The Same Tasks, Four Different Commands

Task	apt (Debian/Ubuntu)	dnf (Fedora/RHEL)	pacman (Arch)	apk (Alpine)
Install	`apt install pkg`	`dnf install pkg`	`pacman -S pkg`	`apk add pkg`
Remove	`apt remove pkg`	`dnf remove pkg`	`pacman -R pkg`	`apk del pkg`
Refresh index	`apt update`	`dnf check-update`	`pacman -Sy`	`apk update`
Upgrade all	`apt upgrade`	`dnf upgrade`	`pacman -Syu`	`apk upgrade`
Search	`apt search term`	`dnf search term`	`pacman -Ss term`	`apk search term`
List installed	`apt list --installed`	`dnf list installed`	`pacman -Q`	`apk info`

Dependency Resolution — Not All Equally Permissive

apt and dnf both resolve dependencies against repository metadata and are relatively tolerant of partial upgrades — installing one new package without a full system update generally works fine on either. pacman is meaningfully stricter, for a reason directly tied to Chapter 4's own rolling-release material.

Arch's own "partial upgrades are unsupported" policy

On a rolling-release system, installed packages and their shared libraries are tightly version-coupled — installing a single new package (pacman -S somepackage) without first fully syncing and upgrading the entire system (pacman -Syu) can pull in a package built against library versions newer than what's currently installed, producing a genuinely broken partial state. The correct habit on Arch specifically is always running a full -Syu before installing anything new, never syncing the index just to grab one specific package in isolation — a real, well-documented policy, not overcaution.

Ansible's Package Module — Abstracting Over All Four

Ansible's ansible.builtin.package module detects whichever package manager is actually present on a target host and calls it automatically — the exact differences this whole chapter just catalogued, abstracted away behind one generic interface:

# Works identically whether the target is Debian, Fedora, Arch, or Alpine
- name: Install a package regardless of distro
  ansible.builtin.package:
    name: git
    state: present

This generic module only supports the lowest common denominator across all four — install/remove/ensure-latest by name. Anything more specific to one package manager (an Arch AUR helper, a Fedora module stream) still requires that manager's own dedicated Ansible module rather than the generic one.

Checking package details before installing

apt-cache policy pkg, dnf info pkg, pacman -Si pkg, and apk info pkg each show detailed information about a package — version, size, dependencies — before committing to an install, the equivalent lookup across all four tools.

Hands-On Exercises

Exercise 1

A user runs pacman -S somepackage directly, without first running a full system upgrade, and ends up with a broken system afterward. Using this chapter's own warn-box, explain what happened and the correct habit going forward.

📄 View solution

Exercise 2

Explain why an Ansible playbook using the generic package module can install git identically across a Debian, a Fedora, and an Alpine machine without three separate tasks, and what real limitation this convenience comes with.

📄 View solution

Exercise 3

Using this chapter's own compare-table, explain why apt and dnf are described as "relatively tolerant of partial upgrades" while pacman genuinely isn't, tying your answer to Chapter 4's own rolling-release material.

📄 View solution

Chapter 6 Quick Reference

The same tasks across four tools: apt/dnf install-remove-upgrade-search-list, pacman/apk equivalents
apt/dnf tolerate partial upgrades reasonably well; pacman genuinely does not — always full-sync before installing anything new on Arch
Ansible's package module abstracts over all four for the lowest-common-denominator tasks; manager-specific modules remain necessary for anything more specialized
Next chapter: Release Models — Point Release vs. Rolling vs. Enterprise