Debian Pre-Depends vs Depends Explained

In the Debian package management system, dependencies control the installation order and operational requirements of software. While the standard Depends field ensures that a prerequisite package is unpacked and configured by the time the dependent package is configured, the Pre-Depends field enforces a much stricter installation sequence. Specifically, Pre-Depends requires that the target dependency is completely unpacked and configured before the dependent package even begins its unpacking process. This article details the structural, operational, and system-level differences between these two relationship fields.

The Standard Depends Field

The Depends field is the default relationship used in Debian packaging. When Package A depends on Package B, the package manager (dpkg and frontend tools like apt) guarantees that Package B will be installed and configured before Package A is considered fully configured and usable.

However, standard dependencies allow significant flexibility during the unpacking stage:

  • Interleaved Unpacking: dpkg can unpack Package A before Package B is unpacked or configured.
  • Script Limitations: Because Package B might not be configured when Package A is being unpacked, Package A's preinst (pre-installation) script cannot reliably call binaries or services provided by Package B.
  • Circular Dependencies: Standard dependencies can tolerate circular references (Package A depends on Package B, and Package B depends on Package A). The package manager breaks the loop by unpacking both packages first and configuring them sequentially afterward.

The Pre-Depends Field

The Pre-Depends field was designed to handle critical scenarios where normal dependency ordering is insufficient. If Package A has a Pre-Depends relationship with Package B:

  1. Strict Ordering: dpkg will refuse to unpack Package A until Package B is fully unpacked and configured (in the installed state).
  2. Availability in preinst: If Package A must execute a binary or use a shared library provided by Package B inside its preinst script, Pre-Depends ensures that resource is already functioning on the host system.
  3. No Interleaving: The package manager cannot unpack the dependent package and resolve the dependency later; the state transitions are strictly serial.

Key Operational Differences

Feature Depends Pre-Depends
Enforcement Point Enforced before the package is configured (postinst). Enforced before the package is unpacked (preinst).
Availability in preinst Not guaranteed; dependency may be unconfigured or not yet unpacked. Guaranteed; dependency is fully configured and usable.
Dependency Cycles Resolvable by unpacking both packages before configuring. Cannot easily resolve cycles; often results in upgrade deadlocks.
Package Manager Burden Minimal; allows maximum flexibility in scheduling installations. High; forces strict serial operations and complicates dependency solving.

When to Use Each Relation

Standard dependencies should be used for virtually all software packages. They provide the package manager with the leeway required to optimize download and extraction order, handle complex dependency graphs, and upgrade large numbers of packages simultaneously.

Pre-Depends is reserved strictly for specialized, low-level system operations, such as:

  • An essential package upgrade where the new version relies on a newer core library (such as libc6) to execute any binary, including basic archive extraction tools.
  • A package whose preinst script must run a specific utility (like an archive unpacker or a database migration tool) provided by another package to prepare the system before extracting its own files.

According to Debian Policy, maintainers must not use Pre-Depends without explicit consensus from the Debian development community, as inappropriate usage can cause dependency resolution deadlocks and break system upgrades.