Package pinning, holds, and version selection

Production fleets pin package versions for stability: every host runs the same version of every critical package, regardless of what the repositories now offer. Version pinning is the discipline that prevents “every host upgraded to a different version on Friday and now we have N bugs”.

Pinning in apt

$ sudo apt-mark hold openssh-server; apt-mark showhold

openssh-server set on hold.
openssh-server

$ sudo tee /etc/apt/preferences.d/no-default-jdk.pref >/dev/null <<EOF
Package: default-jdk
Pin: release o=Ubuntu
Pin-Priority: 50

Package: default-jdk
Pin: version 17.*
Pin-Priority: 999
EOF
sudo apt update

...

The bands are documented in apt_preferences(5) and the boundaries matter — a pin of exactly 1000 does allow a downgrade, and 990 is the line between “prefer” and “default”, not 900:

The 0 < P < 100 band is the one operators reach for and the one most often missing from cheat sheets: it makes a repository available for a deliberate apt install foo/bar without ever letting apt upgrade pull from it.

Prove the pin took effect

A pin file that apt cannot parse is silently ignored — there is no error, the package just upgrades anyway. Never assume; ask:

apt-cache policy openssh-server   # candidate version and the pin that chose it
apt-cache policy                  # priority of every configured origin

If apt-cache policy <package> does not show your pin priority against the origin you pinned, the pin is not doing anything.

Pinning in dnf

$ sudo dnf install openssh-server-9.6p1-3.el9; sudo dnf versionlock add openssh-server; dnf versionlock list

...

$ sudo dnf versionlock delete openssh-server; sudo dnf install openssh-server

...

When to pin

Auditing pinning state across the fleet

$ ansible all -m shell -a 'apt-mark showhold' 2>/dev/null | head

...

Knowledge check