Package Calculus: Unified Dependency Resolution

• Package Calculus is a universal formalism for package dependency resolution built on a hypergraph abstraction and minimal semantic rules.
• It employs logical inference and SAT encoding to capture NP-complete resolution problems and ensure version uniqueness effectively.
• The calculus enables compositional reductions of advanced package features, facilitating cross-ecosystem translations and streamlined dependency analysis.

Package Calculus is a formalism for the abstract semantics of dependency resolution in software package management, designed to unify the core logic underlying a wide variety of package managers. It enables the precise specification, analysis, and automated resolution of package dependencies—accommodating the diversity of dependency languages, versioning policies, and advanced features across ecosystems. At its core, the Package Calculus provides a minimal, universal model on which all practical package manager semantics can be faithfully represented and efficiently manipulated, enabling principled translation and solver sharing between heterogeneous environments (Gibb et al., 20 Feb 2026).

1. Core Syntax and Semantic Foundations

The Package Calculus is founded on a hypergraph-based abstraction of dependency resolution. The basic elements are:

• Packages: Defined as name-version pairs, $P = N \times V$ where $N$ is a countable set of names and $V$ a countable set of versions.
• Repository: A concrete set $R \subseteq P$ enumerating available packages.
• Dependency Relation: A set $\Delta \subseteq P \times (N \times \mathcal P(V))$, where $(n,v)\;\Delta\;(m,vs)$ means $(n,v)$ requires that some version in $vs$ of package name $m$ be present.
• Resolution: A subset $S \subseteq R$ that (a) includes a designated root $r$, (b) is closed under dependencies so every declared dependency is satisfied by some allowable version, and (c) maintains version uniqueness (for each name, at most one version is present).

Formally, the resolution conditions are:

• Root inclusion: $r \in S$
• Dependency closure: For each $(n,v)\in S$, every $(n,v)\Delta(m,vs)$ is witnessed by some $(m,u)\in S$ with $u\in vs$.
• Version uniqueness: For any name $n$, if both $(n,v), (n,v') \in S$ then $v = v'$.

This foundational model renders $\Delta$ as a directed hypergraph over $R$, and resolution as the computation of acceptable vertex subsets (valid configurations) respecting the above rules (Gibb et al., 20 Feb 2026).

2. Logical and Operational Characterization

Resolution in the Package Calculus admits several mathematically substantive characterizations:

• Inference System: Each package $p$ is represented by a logical atom $X_p$. The resolution constraints translate to inference rules:

$\inferrule*[right=Root]{\,}{X_r} \qquad \inferrule*[right=DepClosure]{X_p \quad (p\;\Delta\;(n,vs))}{\bigvee_{u\in vs} X_{(n,u)}} \qquad \inferrule*[right=Uniq]{X_{(n,v)} \quad X_{(n,v')}}{v = v'}$

• SAT Encoding: The constraints are encoded as Boolean formulae with at-most-one version constraints per name, closure requirements, and root inclusion. Efficient SAT solvers or CDCL engines can then be applied directly to real-world dependency resolution (Gibb et al., 20 Feb 2026).

The resolution problem is NP-complete in general, yet tractable in specific subclasses (e.g., acyclic graphs, minimal-version constraints), as established via Theorem 2 in (Gibb et al., 20 Feb 2026).

3. Extension Mechanisms and Reduction to Core

The expressive power of the Package Calculus derives from standardized reductions of advanced package-management language features to the above core representation. The following extension mechanisms are all proven to admit linear-time reduction:

Feature	Reduction Approach	Expressiveness Gained
Conflicts	Toggle-packages and dependency	Mutual exclusion
Concurrent Versions	Renaming w.r.t. version granularity	Multiple major-versions
Peer Dependencies	Auxiliary hyperedges/enforcements	Parent–child peer constraints
Features/Extras	Synthetic packages for features	Fine-grained option selection
Version Formulae	Auxiliary variables and SAT wires	Range and boolean logic
Variable Formulae	Fresh names for variable settings	Cross-arch/platform switching
Virtual Packages	Intermediate nodes/enabler packages	Provider abstraction

For each, the paper proves soundness and completeness of the reduction: every solution of the original extended calculus is faithfully represented and recoverable from a solution to the reduced core instance, and vice versa (Gibb et al., 20 Feb 2026).

4. Universal Intermediate Representation and Translation

The centerpiece of the Package Calculus is its role as a universal IR for dependencies. Since every real-world package manager's feature set reduces to the core, translation between heterogeneous ecosystems can proceed via three steps:

1. Parsing the ecosystem-specific dependency DSL into an extended-calculus instance $(\Delta_A,r_A)$.
2. Lowering/Reduction compositionally to a core instance $(\Delta, r)$.
3. Lifting (inverse reduction) and Emission to the target ecosystem's DSL.

Because all reductions are compositional and preserve solution sets bijectively, only $2n$ front-ends (for $n$ ecosystems) are required rather than the combinatorially more costly $n^2$ direct translators. This universal IR approach enables true cross-ecosystem resolution, analysis, and dependency visualization (Gibb et al., 20 Feb 2026).

5. Theoretical Minimality, Compositionality, and Complexity

Key theoretical findings include:

• Minimality: The three core rules (root inclusion, closure, version uniqueness) are jointly irreducible; omitting or strengthening any would render the calculus insufficient or overly restrictive (Gibb et al., 20 Feb 2026).
• Compositionality: Extensions (e.g., features plus concurrent versions) compose cleanly—reductions may be stacked or ordered with predictable semantics. Some interactions (e.g., conflicts and version uniqueness) require specific sequencing.
• Computational Complexity: Core resolution is NP-complete, yet special cases (e.g., minimum-only policies or absence of conflicts) can reduce to polynomial time via graph algorithms.

6. Illustrative Example: Core Resolution

Consider a repository $R$ with

$(A,1),\ (B,1),\ (C,1),\ (D,1),\ (D,2)$

and dependencies

$$(A,1)\Delta(B,\{1\}),\ (A,1)\Delta(C,\{1\}),\ (B,1)\Delta(D,\{1,2\}),\ (C,1)\Delta(D,\{1\})$$

with root $(A,1)$. The only valid resolution is $S = \{ (A,1), (B,1), (C,1), (D,1) \}$, since both dependencies must be satisfied with a unique version of $D$ due to version uniqueness (even though $(B,1)$ could have chosen either $(D,1)$ or $(D,2)$) (Gibb et al., 20 Feb 2026).

7. Significance and Impact

By isolating a universal minimal core and systematic reduction schemes, the Package Calculus:

• Enables the construction of cross-language, cross-distribution, and cross-ecosystem package management tools.
• Facilitates future research into solver optimizations, new categorical and algebraic interpretations, and correctness proofs for package installer implementations.
• Reduces the combinatorial engineering burden for organizations maintaining polyglot software supply chains (Gibb et al., 20 Feb 2026).

This formalism lays the groundwork for unified package resolution infrastructures, closing longstanding gaps between disparate software component ecosystems.