Version Selection, Holds, Pinning and Dependency Conflicts

An update is available but a package remains at its installed version. The cause may be a hold, candidate policy, phased rollout, dependency constraint or a failed transaction. A single “kept back” message does not identify which one.

Use bl05-packages-lab, where the previous transaction installed tree after verifying that it was initially absent and not held. Keep the learner console, original bl02 powered off and the package-lab evidence. This chapter briefly holds and unholds only tree; it does not change repository priorities or force a downgrade.

Installed, candidate and available

dpkg-query -W -f='${db:Status-Abbrev} ${Version}\n' tree
apt-cache policy tree
apt-mark showhold
sudo apt-get -s upgrade

The installed version is local package state. The candidate is APT’s current preferred version under its available metadata and policy. A simulated upgrade shows a proposed transaction, including packages that may be deferred. Read the complete result; a hold can affect automatic upgrade behavior even when a newer candidate exists. Other causes include dependency changes, pin priorities, phased updates or a policy that requires a different transaction type.

A simulation does not reserve packages or prevent another job from changing the state. apt-cache policy does not prove that a candidate was installed, tested or supplied by a particular repository in an earlier transaction.

Priorities and pins

APT preferences assign priorities to versions. Default priorities vary with installed state, target release and archive metadata; phased updates can also affect eligibility. APT normally avoids downgrades unless a sufficiently high priority or explicit choice changes that behavior. When priorities tie, version ordering matters. The APT preferences manual documents the complete algorithm and warns that careless preferences can make packages uninstallable.

Inspect existing preferences without editing them:

ls -l /etc/apt/preferences /etc/apt/preferences.d
apt-cache policy tree

An absent optional file is normal. Review actual .pref files only if present, and protect private repository details. A pin is a selection rule, not a guarantee that the resulting combination is supported or secure. Mixing unrelated release suites can select incompatible libraries; do not copy a pin from another host or assign an extreme priority just to force a desired answer.

A hold is a package selection state that suppresses certain automatic package changes. It is not a security update plan, a dependency lockfile or an absolute barrier to every explicit administrative operation. Record why it exists, who owns it, when to review it, and which security fixes are deferred. The apt-mark manual describes hold and unhold.

Lab: hold and release the disposable package

First reconfirm the exact target and preconditions:

hostnamectl
dpkg-query -l tree
apt-mark showhold

Proceed only on the identified package clone, with tree fully installed and absent from the hold list. If it was already held, do not overwrite another operator’s policy. Record the installed version and pre-existing hold list.

sudo apt-mark hold tree
apt-mark showhold
apt-cache policy tree

Confirm tree appears in the hold list. The candidate output may remain unchanged: a hold and candidate selection are different views. You need not have a newer version available to demonstrate the hold state; do not fabricate an upgrade result.

Restore the original state:

sudo apt-mark unhold tree
apt-mark showhold
dpkg-query -l tree

Verify that tree is no longer held and is still installed. If unhold fails, preserve the output and leave the clone’s record open; do not report rollback complete. No package version was changed by these hold commands.

Investigate a dependency conflict

For a reported package, inspect its installed state, candidate and declared relationships:

apt-cache policy tree
apt-cache depends tree
apt-cache rdepends tree
sudo apt-get -s install tree

A Depends line can include alternatives and version constraints; reverse dependencies show metadata relationships, not proof that every listed package is installed or in active use. Review the full simulated proposal and its error. A request for an explicit package=version is still subject to available metadata and dependency constraints, and a real installation can change or remove other packages. Do not force a version or downgrade the lab’s core libraries to make the simulation succeed.

For a real conflict, record the enabled sources, installed and candidate versions, holds, preferences and the exact resolver message. Determine a supported set of packages, service impact and recovery path before changing policy. A version rollback can leave newer data formats or configuration incompatible with the older program; a package downgrade is not a complete application rollback.

Keep tree on the clone for the next configuration chapter, then remove it as directed there. Keep the original guest unchanged.

Recall card

• Installed version, APT candidate and hold state answer different questions.
• Pins affect selection; they do not prove compatibility or safety.
• A hold needs an owner, expiry/review decision and security-update plan.
• Read the whole resolver proposal and preserve a recovery path before changing versions.