4.7 Roots and Resolution
A dependency is satisfied within a specific installation root. By
default that is the same root as the depending package, so a package's
closure flows into the root the package occupies. A dependency's root
field overrides that, naming a different one.
4.7.1 Two resolution modes #
peipkg resolves in one of two modes.
Cross-root resolution honours a dependency's root field, placing
the dependency in the root it names and producing a plan whose
operations are grouped by root.
Single-root resolution treats every operation as belonging to one
root. A dependency carrying a root field is placed in the depending
package's root instead, and the field has no effect.
install resolves cross-root. Default upgrade also uses cross-root
resolution in peipkg 8b588ae8;
--no-recurse confines upgrade resolution and execution to the current
root. The cross-root dependency chapter
keeps that source-backed distinction separate from the earlier descriptions
of downgrade, uninstall, and undo, whose paths are not verified by
this upgrade correction.
4.7.2 Top-level placement #
Where an operator names a package directly with no explicit root, the
package's default_root decides where it lands. A dependency's
placement is never governed by the dependency's own default_root; only
by the depending package's root and the dependency's root field.
4.7.3 Cascading across roots #
Default upgrade resolves the current root and its reachable named roots into one plan, with one approval. A named package is considered in each reachable root where it is installed. If the plan changes multiple roots, the coordinated executor verifies all packages, prepares the participants, then attempts commits root by root. Preparation failure attempts rollback; a commit failure can leave partially committed work needing recovery. These are not independent continue-on-error upgrade transactions.
See Named roots for operator checks and the pinned source/release scope, and transaction scope for the execution boundaries.