How Ubuntu APT Pinning Lets You Decide Which Updates Get Installed

Why Pinning Matters in Ubuntu

When you run apt upgrade, the package manager pulls the newest versions from all enabled repositories. That behaviour is fine for most users, but in production or long‑term‑support (LTS) environments you often want tighter control. APT pinning lets you set numeric priorities for each repository or even individual packages, telling the resolver which version to choose when conflicts arise.

Without pinning, a security update from security.ubuntu.com will always win, but a feature release from proposed.ubuntu.com could still be pulled if you enable that repo. Pinning turns that uncertainty into a predictable policy.

How APT Pinning Works

APT pinning rules live in /etc/apt/preferences (or /etc/apt/preferences.d/*.pref). Each rule looks like this:

# Example pinning rule for the security repo
Package: *
Pin: release o=Ubuntu, n=jammy-security
Pin-Priority: 1000

Rules are evaluated in order of priority: higher numbers win. The table below summarizes the effect of different ranges.

Priority Range	Effect
> 1000	Force installation of the specified version, even if it’s older.
500–1000	Prefer this source over others, but allow upgrades from higher‑priority repos.
0–499	Use this source only if no higher‑priority candidate exists.
< 0	Disallow installation of the package from this source.

By default, Ubuntu LTS systems give the security repo a priority of 1000, the main repo 500, and the proposed repo 400. This means security updates always win, but feature updates can still be pulled if you enable the proposed repo and don’t override it.

Practical Example: Locking a Package to a Specific Version

Suppose you run an application that depends on libssl1.1 and you want to keep the 1.1.1f release even when a newer security patch appears. You can pin that package to the desired version.

# /etc/apt/preferences.d/libssl.pref
Package: libssl1.1
Pin: version 1.1.1f-1ubuntu2
Pin-Priority: 1000

After adding the file, run:

sudo apt update
sudo apt policy libssl1.1

The output will show the installed version, the candidate (which will still be 1.1.1f-1ubuntu2 because of the high priority), and the priority source. If you later decide to allow the newer security update, either delete the file or change the priority to a lower value.

Trade‑offs and Limitations

• Security risk: Pinning a package to an older version can block critical security patches. Always review the security advisory list before lowering a priority.
• Dependency headaches: A third‑party PPA combined with custom pinning often leads to unmet dependencies. Use apt-cache policy system‑wide to spot unexpected overrides.
• Upgrade friction: In a CI/CD pipeline, hard‑coded pinning can cause builds to fail when a new dependency version is required. Consider pinning only the most critical packages.
• Maintenance overhead: Pinning rules are static; they don’t adapt to new upstream releases unless you manually edit the file.

Testing Your Pinning Configuration

Before deploying pinning to production, validate it in a staging environment:

1. Run sudo apt update to refresh metadata.
2. Check candidate versions: apt policy <package> for each pinned package.
3. Simulate an upgrade: sudo apt-get -s upgrade (the -s flag performs a dry run).
4. Verify that the resolver selects the expected versions and that no unmet dependencies appear.

If the dry run reports conflicts, adjust the priority or remove the pinning rule for that package.

Actionable Takeaway

APT pinning is a powerful tool for fine‑grained update control, but it requires careful planning. Start by pinning only the packages that truly need stability, keep your priorities aligned with security best practices, and always test changes in a non‑production environment. With a clear pinning strategy, you can balance the need for fresh features against the stability of your Ubuntu deployment.