Package management overview — apt vs dnf

A package manager is the system that installs, removes, queries, and verifies the software on a Linux host. Manual installation (tar -xzf, make install) bypasses the package manager and produces unmaintainable, unauditable systems.

Why package managers exist

The original UNIX way was “compile from source”. Linux distributions replaced that with packages: pre-built binaries with metadata (name, version, dependencies, files, scripts). The package manager:

• Tracks every file installed by the package.
• Tracks dependencies between packages.
• Verifies package signatures before installation.
• Manages the upgrade path.
• Allows clean removal.

$ apt list --installed 2>/dev/null | head; dnf list installed 2>/dev/null | head

accountsservice/now 23.13.9-2ubuntu2 amd64 [installed,upgradable to: 23.13.10]
adduser/noble,now 3.137ubuntu1 amd64 [installed,local]
apparmor/noble,now 4.0.1-0ubuntu4 amd64 [installed,local]
...

The two main families

Most comparison tables collapse the upgrade rows into a single apt update && apt upgrade versus dnf upgrade. That mapping is wrong, and it is the wrong kind of wrong: the two commands do different amounts of work. apt update only refreshes the package lists and upgrades nothing. apt upgrade is more conservative than dnf upgrade, not equivalent to it.

upgrade vs full-upgrade, and “kept back”

apt upgrade will never remove an installed package. If an upgrade cannot be completed without removing something, apt silently skips that package and reports it as held back:

The following packages have been kept back:
  linux-generic linux-headers-generic linux-image-generic
0 upgraded, 0 newly installed, 0 to remove and 3 not upgraded.

apt full-upgrade performs the same job but is permitted to remove packages in order to upgrade the system as a whole. It is the same operation as the older apt-get dist-upgrade.

Neither command is “the safe one”. They trade different risks:

Work out why a package is held back before you reach for full-upgrade:

$ apt list --upgradable; apt-mark showhold; sudo apt-get -s dist-upgrade

Listing... Done
linux-generic/noble-updates 6.8.0-45.45 amd64 [upgradable from: 6.8.0-41.41]
...
The following packages will be REMOVED:
linux-image-6.8.0-41-generic
The following packages will be upgraded:
linux-generic linux-headers-generic linux-image-generic
3 upgraded, 3 newly installed, 1 to remove and 0 not upgraded.

The rule for a patching run: simulate with apt-get -s dist-upgrade, read the removals, then run apt full-upgrade with the removal list already understood. An unattended full-upgrade on production, with nobody having read the Remv lines, is how a monitoring agent disappears during a patch window.

$ dpkg -l openssh-server 2>/dev/null; rpm -q openssh-server 2>/dev/null

Desired=Unknown/Install/Remove/Purge/Hold
| Status=not/known/ok | err?=(none)/Reinst-required...
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name           Version      Architecture Description
+++-==============-============-============-=================================
ii  openssh-server 1:9.6p1-3ubun amd64        secure shell (SSH) server...

What a package contains

A package is more than the binary. The metadata includes:

• Pre-install and post-install scripts (run by the package manager).
• Conffiles — configuration files the package manager tracks separately (so an upgrade does not overwrite your edits unless you choose to).
• Triggers — events that cause dependent actions (e.g., regenerating the initramfs after a kernel update).
• File list with permissions, owners, and checksums.
• Dependency declarations.
• Digital signature.

$ dpkg -L openssh-server 2>/dev/null | head; rpm -ql openssh-server 2>/dev/null | head

/.
/usr
/usr/lib
/usr/lib/openssh
/usr/lib/openssh/sshd-keygen
/usr/lib/systemd
/usr/lib/systemd/system/sshd.service
/usr/sbin
/usr/sbin/sshd
...

Conffiles across an upgrade

A conffile is a configuration file the package manager tracks separately, so an upgrade does not blindly discard your edits. What happens when both you and the vendor changed the file depends on the packaging system.

Note what RPM does not do: it does not simply replace your file. Most RHEL service configs, including /etc/ssh/sshd_config, are marked %config(noreplace), so your hardening survives and the vendor’s new options land in a .rpmnew file that nobody reads unless you go looking.

Automated patching has to answer the Debian prompt in advance, or it will hang on a host with no terminal attached:

sudo DEBIAN_FRONTEND=noninteractive apt-get -y \
     -o Dpkg::Options::=--force-confdef \
     -o Dpkg::Options::=--force-confold upgrade

• --force-confold keeps your existing file.
• --force-confdef lets dpkg take the default action where it has one, so the prompt never appears.
• --force-confnew is the opposite policy: take the vendor file, discard yours. Use it only where configuration is managed elsewhere, such as by Ansible or Puppet.

Then sweep for the files the upgrade could not merge. This belongs in every post-patch validation, on both families:

find /etc \( -name '*.dpkg-dist' -o -name '*.dpkg-old' \
          -o -name '*.ucf-dist' \) 2>/dev/null
find /etc \( -name '*.rpmnew' -o -name '*.rpmsave' \) 2>/dev/null

Production discipline

• Pin package versions for production stability.
• Use a configuration-management tool to ensure all hosts have the same package set.
• Mirror repositories locally for offline and predictable installs.
• Verify package signatures (default in modern apt/dnf).
• Treat every kept-back package as an unapplied update, not a cosmetic message.
• Sweep /etc for .dpkg-dist, .dpkg-old, .rpmnew and .rpmsave after every patch run, and resolve each one.
• Audit installed packages quarterly for unnecessary dependencies.

Knowledge check