Dependencies, holds, and pinning

Dependency types have different semantics — apt treats them very differently. Understanding the difference explains why apt install --no-install-recommends can dramatically reduce disk usage on a server.

# View all dependency fields for a package
apt-cache show nginx | grep -E '^(Depends|Recommends|Suggests|Pre-Depends|Conflicts|Breaks):'

# Depends: MUST be installed; apt will refuse to install without them
# Recommends: installed by default but skippable; --no-install-recommends skips them
# Suggests: informational only; never auto-installed
# Pre-Depends: like Depends but must be configured BEFORE this package is unpacked
# Conflicts: cannot be installed alongside the listed package
# Breaks: the listed package would malfunction if installed alongside this one

On a minimal server, --no-install-recommends is often appropriate:

# In a Dockerfile: saves 30-60% on image size for many packages
RUN apt-get install -y --no-install-recommends nginx

Pre-Depends are rare but critical: they exist for packages like libc6 that must be fully configured before anything else on the system is touched, because dpkg itself depends on them.

Version constraints let package maintainers express compatibility precisely. You will see them in apt-cache show output and in your own dependency specifications:

Depends: libssl3 (>= 3.0.0), libpcre3 (>= 1:8.31), nginx-common (= 1.18.0-6ubuntu14.4)

# Check if an installed package satisfies a constraint
dpkg --compare-versions "1.18.0-6ubuntu14.4" ">=" "1.18.0" && echo "satisfies" || echo "does not"
# satisfies

# This is exactly what apt runs internally when resolving

The Debian epoch prefix (1: in 1:8.31) overrides normal version sorting. A package version 1:0.1 sorts higher than 9.99 because the epoch number wins. Epochs exist when a package’s versioning scheme changed upstream and the new version number is numerically lower than the old one.

apt-mark hold freezes a package at its installed version. apt upgrade will skip held packages entirely — they will not be upgraded even when a newer version is available.

# Hold a package at its current version
sudo apt-mark hold nginx
# nginx set on hold.

# Verify
apt-mark showhold
# nginx

# Check dpkg status — it now shows "hi" (hold + installed)
dpkg -l nginx
# hi  nginx  1.18.0-6ubuntu14.4  ...

# apt upgrade will warn about held packages:
# The following packages have been kept back: nginx

# Remove the hold when you are ready to upgrade
sudo apt-mark unhold nginx

The most common use: holding the kernel on a server with an out-of-tree module until the module vendor releases a compatible build. The gotcha: a held package can block security updates for packages that depend on it. Run apt upgrade periodically and check what is being kept back — a held package should be a deliberate, reviewed decision, not something you forgot from six months ago.

Pinning controls which version apt prefers when multiple repositories provide the same package. The file /etc/apt/preferences (or files in /etc/apt/preferences.d/) assigns numeric priorities. The highest priority wins.

# /etc/apt/preferences.d/backports-pin
# Default priorities:
#   500  = packages from the target release (your main suite)
#   100  = installed packages and packages from non-target releases
#   1    = "never automatically install from this source"
#   -1   = "never install, even if explicitly requested"

# Pin nginx to the backports version (priority 900 > default 500)
Package: nginx
Pin: release a=jammy-backports
Pin-Priority: 900

# Pin everything else from backports LOWER than stable (prevents mass upgrades)
Package: *
Pin: release a=jammy-backports
Pin-Priority: 100

# Check effective policy for a package — shows which repo wins
apt-cache policy nginx
# Installed: 1.18.0-6ubuntu14.4
# Candidate: 1.25.3-1~jammy  ← backports wins due to pin priority 900
# Version table:
#  1.25.3-1~jammy 900        ← from jammy-backports (pinned)
#     ...
#  1.18.0-6ubuntu14.4 500    ← from jammy (standard priority)

A pin priority above 1000 will even downgrade an installed package to the pinned version — extremely dangerous in production, used only for emergency rollbacks.

Dependency conflicts occur when two packages cannot coexist. Conflicts: means “dpkg refuses to install both simultaneously”. Breaks: means “I would work but the listed package would malfunction alongside me.”

# Example: trying to install two conflicting packages
sudo apt install apache2 nginx-full
# The following packages conflict:
#   nginx-full conflicts with apache2 (both bind port 80 by default)

# Resolution: remove the conflicting package first
sudo apt remove apache2
sudo apt install nginx-full

# Simulate what apt would do without touching disk
apt-get install -s nginx-full  # -s = simulate

# When apt says "held broken packages" during upgrade:
sudo apt install -f   # fix broken: installs missing deps, removes conflicting ones

apt install -f (fix) is the first response to a broken dependency state. It does not randomly install things — it reads the current dpkg state and installs or removes exactly what is needed to reach a consistent state. If -f itself fails, read the error carefully: it usually names a specific conflicting package.