Pith. sign in

REVIEW 3 major objections 6 minor 60 references

Solving Package Management via Hypergraph Dependency Resolution

T0 review · 3 major / 6 minor · reviewed 2026-08-07 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read The paper claims that all versioned dependency resolution can be captured in one hypergraph formalism, and that a single SAT pass over that hypergraph can resolve projects spanning OCaml, Rust, Python, and Debian together.

desk verdict HyperRes is a sound formal proposal with a genuinely useful survey, but its cross-ecosystem demonstration and its acyclicity encoding do not yet hold up; send it to review with requests for artifacts and fixes. read the letter →

arxiv 2506.10803 v1 pith:PKNWSCBY submitted 2025-06-12 cs.SE cs.PL

Ryan Gibb , Patrick Ferris , David Allsopp , Michael Winston Dales , Mark Elvers , Thomas Gazagnaire , Sadiq Jaffer , Thomas Leonard
show 2 more authors
Jon Ludlam Anil Madhavapeddy
This is my paper · ORCID
classification cs.SEcs.PL
keywords packagemanagementdependencyresolutionhypergraphSATsolvingcross-ecosysteminteroperabilityversionconstraintsmetadatatranslationsoftwaresupplychain
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

The paper sets out to prove that versioned dependency resolution, across operating-system and language package managers alike, has a single common core: a directed hypergraph whose vertices are package name-version pairs and whose hyperedges are labelled as strong dependencies, optional dependencies, or conflicts. It claims this HyperRes formalism is expressive enough to model real managers such as APT, opam, Cargo, and Nix, and that resolution over the hypergraph is a mechanically solvable SAT instance even though the decision problem is NP-complete. From there it argues that ecosystems can be joined in one hypergraph, so a project mixing OCaml, Rust, Python, and system libraries resolves in a single pass, and that package metadata can be translated bidirectionally between ecosystems—for instance, mechanically producing a Debian binary package from a multi-language source project. The reason a reader should care is that, if true, the manual per-distribution, per-architecture, per-language packaging labour collapses into one semantic core plus faithful translations.

What carries the argument

The central object is the resolution hypergraph: a directed hypergraph whose vertices are package name-version pairs, with hyperedges labelled $\delta$ (dependency), $\sigma$ (optional dependency), or $\gamma$ (conflict), together with the SAT encoding that turns any such hypergraph and query set into a CNF instance. The hypergraph carries the whole argument because it gives a single place where versioned constraints from different ecosystems can coexist, and the SAT encoding is what makes resolution mechanical; the paper also shows how to absorb features into versions, architecture into packages, and boolean package formulae into virtual packages, so the one mechanism covers APT, opam, Cargo, and Nix semantics.

What would settle it

Resolve a specific real multi-ecosystem project, such as the paper's polars example, twice: once with HyperRes and once with the native package managers (opam, Cargo, APT) running separately; if the HyperRes result contains a version the native tools reject, omits a version the native tools require, or fails to find a solution when the native tools succeed, the faithfulness claim is falsified. A sharper check is to translate a known opam package with a complex version formula into HyperRes and verify that the set of satisfying assignments equals the set of native-resolver selections.

Watch

Extended reading notes

Core claim

The central discovery is that the shared essence of package managers is a hyperedge-labelled directed hypergraph. Vertices are packages as name-version pairs; hyperedges carry one of three labels—dependency (one package needs at least one of a set), optional dependency (used only if already present), or conflict (cannot coexist). Dependency resolution is defined as mapping a query set and hypergraph to a resolved graph satisfying four conditions: the query packages are present, every dependency is satisfied by exactly one chosen package, optional dependencies are honoured when their partner is present, and no conflicts are included. The paper proves the DependencyResolution decision problem is NP-complete by a polynomial reduction from SAT, and also supplies the reverse encoding, showing any instance can be handed to a SAT solver. Adding an ecosystem labelling to the hypergraph lets one resolution span multiple package ecosystems, with translations 'on-ramping' metadata into the graph and 'off-ramping' selected packages to native installers; the paper reports translations covering just over 1.7 million packages across APK, Cabal, Cargo, CentOS, Debian, Fedora, Homebrew, opam, OpenSUSE, and Pacman, and demonstrates a resolved subgraph for opam's polars library pulling in Cargo and Debian packages.

Load-bearing premise

The load-bearing premise is that translating each ecosystem's metadata into HyperRes—especially expanding version formulas such as 'ocaml >= 4.14.0 & < 5.0.0' into explicit version sets—preserves exactly the set of valid package selections the native package manager would compute, since HyperRes itself attaches no semantics or ordering to versions.

Editorial extensions

If this is right

  • If HyperRes is correct, one SAT-based resolution over a cross-ecosystem hypergraph yields a consistent, deployable package set for a mixed-language project, without switching users away from their existing package managers.
  • Package metadata becomes bidirectionally translatable between ecosystems, so a Debian binary package could be produced mechanically from OCaml, Rust, or Python metadata, reusing packaging knowledge instead of repeating per-distribution labour.
  • System and hardware dependencies—kernel versions, GPU drivers, CPU architectures—can be expressed as versioned cross-ecosystem packages, making deployments reproducible instead of relying on ad-hoc and unversioned assumptions.
  • The same hypergraph can serve as a common layer for generating software bills of materials and reasoning about supply-chain security across language and OS ecosystems.
  • Because DependencyResolution is NP-complete yet solvable by the given SAT encoding, solver performance is the practical bottleneck, and the paper reports that it scales with the dependency cone rather than the full repository.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • The paper's deliberate decision to attach no ordering or semantics to versions pushes all faithfulness onto the translation layer; a natural testable extension is to fuzz-compare HyperRes resolutions against native resolvers on random dependency cones to check that the expanded version sets exactly match native selections.
  • If the 1.7-million-package translation were released and validated, HyperRes would effectively be a common interchange format for package metadata, which could push package managers toward a shared 'protocol'—the paper sketches this possibility but does not implement it.
  • Encoding features as extra versioned packages (Section 4.3.2) may create a combinatorial explosion for packages with many feature combinations; the paper does not analyze this blow-up, so a practical extension would be to measure vertex growth on real Cargo packages.
  • The cross-ecosystem resolution idea suggests a benchmark for reproducibility: take the same multi-language project, resolve it with HyperRes and with the union of native managers, and check whether the resulting filesystem trees are binary-compatible; the paper's Debian-dependencies note admits these are currently ad-hoc and unversioned.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

3 major / 6 minor

Summary. The paper introduces HyperRes, a hypergraph-based formalism for dependency resolution in which vertices are package name-version pairs and labelled hyperedges represent strong dependencies, optional dependencies, and conflicts. It defines the DependencyResolution decision problem, proves it NP-complete via a reduction from SAT, gives a CNF-SAT encoding for solving it, and sketches encodings of APT, opam, Cargo, and Nix features. It then claims to bridge ecosystems by translating metadata from many package managers into HyperRes and resolving dependencies across ecosystems in one pass, supported by a prototype covering roughly 1.7 million packages and one cross-ecosystem resolved example involving opam, Cargo, and Debian. The paper also outlines a vision for bidirectional metadata translation between ecosystems.

Significance. If the formal core is correct, HyperRes offers a clean and useful common abstraction for comparing and combining package managers, and the NP-completeness proof and SAT encoding are straightforward but serviceable. The survey of 36 package managers and the classification of their properties into a common pipeline is a useful contribution. However, the central cross-ecosystem claim currently rests on unverified translations and a single example whose Debian dependencies are admitted to be ad-hoc and unversioned. The paper ships no code, data, or fidelity checks against native resolvers, so the empirical part is a demonstration sketch rather than a validated system. The formalization of opam's acyclic-resolved-graph requirement in §4.2.2 is also incorrect as written, which weakens the claim that HyperRes can faithfully model opam. The paper is honest about some of these limitations, but they are load-bearing for the main claims.

major comments (3)
  1. [§4.2.2] The formal condition for opam's acyclic resolved graph is not acyclicity. The text states that for any sequence of edges e1,...,en in G where ei = (pi, ei), it holds that pi != p_{i+1}; even if we charitably read this as edges (pi, e_i) with e_i the head, a two-edge cycle (A,B),(B,A) satisfies p1=A != p2=B and yet is cyclic. The condition is also ill-formed because ei is used both as an edge and as a package. Moreover, the SAT encoding in §3.3 contains no acyclicity constraint at all, so the paper does not establish that HyperRes, as formally defined and encoded, can enforce the opam resolved-graph requirement or the 'post' exception mentioned in the same section.
  2. [§5.2] The claim in the abstract that HyperRes can 'solve dependency constraints across' ecosystems is supported only by one resolved graph (Figure 11). The authors state that in this example the Debian dependencies are 'ad-hoc and unversioned', and no comparison against native resolvers (opam, cargo, apt) is reported, no translator code or data are released, and no fidelity measurement is given for the claimed 1.7-million-package translation corpus. As it stands, the cross-ecosystem resolution result is not reproducible and cannot substantiate the asserted ability to produce binary-compatible, deployable package sets. The authors should provide the translators, a validation protocol that compares HyperRes solutions with native resolver outputs on a meaningful sample, or at minimum a precise statement of which translations were actually exercised.
  3. [§1.1.1 and §3.1] HyperRes deliberately attaches no semantics or ordering to versions, but the translation of a version formula such as 'ocaml >= 4.14.0 & < 5.0.0' into an explicit set of version vertices is an external, unverified step. If that expansion does not exactly match the version-comparison and range semantics of the native package manager, a HyperRes solution may select packages the native resolver would reject, or miss valid ones. The paper does not specify the expansion algorithm for any ecosystem or provide evidence that its expansions agree with native behavior. Since the faithfulness of these translations is the premise for the cross-ecosystem validity claim, this gap needs to be addressed either by formal proofs of translation equivalence or by empirical validation against native resolvers.
minor comments (6)
  1. [§3.3] The clause '∀(p,d)∈D, ∀e∈d, ∃X_(p,e)' uses an undefined symbol D; it should range over the dependency relation, e.g., over all pairs (p,d) with d∈deps(p).
  2. [§3.3] In the at-most-one clause for optional dependencies, the quantifier ranges over e1,e2∈d; it should range over e1,e2∈o, since o is the optional dependency set.
  3. [§4.1.4] The text says both openssh-server and dropbear-bin provide the virtual package openssh-server, but the running example in §1.1.6 uses the virtual package ssh-server. The example is inconsistent and should be corrected.
  4. [§4.3.2] The definition of FV_n uses an undefined variable s: 'FV_n = {(v,s) | f∈F(n,v), v∈V_n}' should presumably be '{(v,f) | f∈F(n,v), v∈V_n}'.
  5. [§4.3.2] The sentence 'Not that we omit separators between versions and features for the sake of brevity' should be 'Note that we omit separators...'.
  6. [§3.1] The word 'Similarity' appears where 'Similarly' is intended.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the formal core is anchored to external SAT semantics, and the Section 5.2 implementation is self-referential only as an unvalidated demonstration, not as a derivational circle.

full rationale

The paper's derivation chain is self-contained at the formal level. Section 3.1 defines the resolution hypergraph, resolved graph, and the four resolution criteria independently of any implementation or fitted parameter. Section 3.2 gives a direct polynomial reduction from SAT, constructing conflict packages for variables and clause packages for disjunctions, and the argument that a satisfying package set corresponds exactly to a satisfying truth assignment is a standard external reduction. Section 3.3 provides the reverse SAT encoding with explicit soundness and completeness arguments; the SAT clauses are direct transcriptions of the definitions in Section 3.1, so the equivalence is proved rather than assumed. Section 4 models APT, opam, Cargo, and Nix by encoding their features (single-version conflicts, version ordering, virtual packages, boolean algebra, feature versions, acyclic graphs) into the formalism; these are modelling choices, not fitted inputs renamed as predictions. No self-citation is load-bearing: the references are to external prior work on SAT-based package resolution, not to the authors' own theorems, and there is no imported uniqueness claim. The only self-referential element is Section 5.2, where the authors' own translators build the hypergraph used to demonstrate the authors' own resolver. The paper itself notes, 'In the current state these Rust dependencies are vendored into the projects source repository, and Debian dependencies are ad-hoc and unversioned,' and it ships no artifacts or fidelity checks against native resolvers. This is a real validation gap for the cross-ecosystem deployment claim, but it is not a case of a conclusion being equivalent to its inputs by construction: the translation and resolution steps are independent procedures, and the formal results do not depend on them. The NP-completeness and SAT-encoding results would stand even if every translator were removed. Accordingly, the circularity score is 0.

Assumptions & free parameters 0 free parameters · 7 assumptions · 3 invented entities

No numeric parameters are fitted to data anywhere in the paper; the hand-chosen elements are design decisions (three edge labels, virtual packages with empty version epsilon, the version-preference heuristic in Sec. 4.1.2) rather than fitted quantities. The formal core rests on standard math (SAT NP-completeness, hypergraph definitions) plus domain assumptions: the sufficiency of three relation types, exactly-one semantics per dependency set, version sets without intrinsic ordering, and the well-definedness of ecosystem labelling. Two of these assumptions are fragile: the ecosystem labelling (Sec. 5.1) is ambiguous for colliding package names, and the acyclicity modelling (Sec. 4.2.2) is stated with a condition that does not enforce acyclicity. The feature-encoding extension also assumes a single feature set applies across all satisfying versions (Sec. 4.3.2).

assumptions (7)
  • standard math SAT is NP-complete (Cook-Levin)
    Invoked in Sec. 3.2 for the NP-hardness reduction; standard background.
  • standard math Berge hypergraph definitions
    Background for directed hypergraphs, cited as [20] and used in Sec. 3.1.
  • domain assumption Dependency, optional-dependency, and conflict relations suffice to model the surveyed package managers
    Sec. 3.1 restricts hyperedge labels to {delta, sigma, gamma}; features and OS parameters are encoded via auxiliary packages rather than added as primitives.
  • domain assumption Versions carry no inherent ordering or semantics; ordering and preference are external to the formalism
    Stated in Sec. 3.1; freshness preference in Sec. 4.1.2 is layered on as a solver heuristic rather than part of the semantics.
  • domain assumption Exactly-one semantics for each dependency set (exists! in Sec. 3.1 condition 2)
    Chosen to match Debian-style resolvers; not all ecosystems behave this way, e.g., Go's minimal version selection applies a different selection rule.
  • domain assumption Ecosystem labelling L_e is well-defined over the union of namespaces
    Sec. 5.1 defines N as the union of namespaces and builds P_t over all n in N; when two ecosystems share a package name with overlapping versions, L_e cannot assign a unique ecosystem, so the formalism is under-specified unless names are prefixed as in Figure 11.
  • ad hoc to paper The sequence condition in Sec. 4.2.2 captures opam's acyclic-resolved-graph requirement
    As written, p_i != p_{i+1} only forbids consecutive repeats and admits cycles of length 3 or more, so the claimed formalization does not enforce acyclicity.
invented entities (3)
  • Virtual packages with empty version epsilon, e.g., (&, epsilon) and (q, epsilon)
    purpose: Encoding conjunctions, boolean-algebra subexpressions, upgrade requests, and query nodes
    Introduced in Sec. 3.2, Sec. 4.1.3, and Sec. 4.2.1 as construction devices; they have no external counterpart and their semantics are entirely internal to the encoding.
  • Feature-version packages (n, (v, f))
    purpose: Encoding Cargo-style features as alternative versions of a package
    Sec. 4.3.2 defines V'_n = V_n union FV_n; these are internal encoding devices, and the encoding assumes the same feature set applies to all versions satisfying a dependency.
  • Parameter packages such as (arch, x86_64), (os-distribution, debian), (linux-kernel, 5.10.7) independent evidence
    purpose: Modeling deployment environment parameters as selectable packages with mutual conflicts
    Sec. 4.1.5, Sec. 4.2.1, and Sec. 5.1 encode real external facts (architectures, distributions, kernels) and yield testable constraints, e.g., selecting (arch, x86_64) must exclude arm64 packages.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Solving Package Management via Hypergraph Dependency Resolution." pith.science (2026). https://pith.science/paper/PKNWSCBY

@misc{pith2026250610803,
  author       = {Pith},
  title        = {Pith review of: Solving Package Management via Hypergraph Dependency Resolution},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/PKNWSCBY}},
  note         = {Machine review of arXiv:2506.10803}
}
read the original abstract

Package managers are everywhere, with seemingly every language and operating system implementing their own solution. The lack of interoperability between these systems means that multi-lingual projects are unable to express precise dependencies across language ecosystems, and external system and hardware dependencies are typically implicit and unversioned. We define HyperRes, a formal system for describing versioned dependency resolution using a hypergraph that is expressive enough to model many ecosystems and solve dependency constraints across them. We define translations from dozens of existing package managers to HyperRes and comprehensively demonstrate that dependency resolution can work across ecosystems that are currently distinct. This does not require users to shift their choice of package managers; instead, HyperRes allows for the translation of packaging metadata between ecosystems, and for solving to be precisely specialised to a particular deployment environment.

Figures

Figures reproduced from arXiv: 2506.10803 by the authors.

Figure 1
Figure 1. An example cross-ecosystem hypergraph illustrating some of the challenges in package management. [PITH_FULL_IMAGE:figures/full_fig_p003_1.png] view at source ↗
Figure 2
Figure 2. The package management pipeline showing mappings between data structures, [PITH_FULL_IMAGE:figures/full_fig_p006_2.png] view at source ↗
Figure 3
Figure 3. Example of a resolution from 𝐻 and 𝑞 = 𝐴1 to 𝐺. The resolution hypergraph is a hyperedge-labelled directed hypergraph, where a hyperedge represents a relationship from one package to a set of packages. The type of this relationship is denoted by a hyperedge￾label and is one of ‘dependency’, ‘optional dependency’, or ‘conflict’. The resolution hypergraph is resolved to a subgraph which satisfies the dependency constr… view at source ↗
Figures from the paper (8 more)
Figure 4
Figure 4. Figure 4: A resolution hypergraph 𝐻 exhibiting the ‘diamond problem’. 4.1.1 Single Versions. As with many packages managers APT only supports deploying a single version of a package name at a time (§2.2.5). We can encode this in the HyperRes formalism by saying for each package …
Figure 5
Figure 5. Figure 5: A resolution hypergraph expressing an upgrade. 4.1.3 Upgrades. The feedback mapping in [PITH_FULL_IMAGE:figures/full_fig_p015_5.png]
Figure 6
Figure 6. Figure 6: Encoding computer architecture in the resolution hypergraph. 4.1.5 Computer Architecture. Packages managers that provide binary packages often provide different versions of a package for different architectures, and APT is no exception. APT points to different package …
Figure 7
Figure 7. Figure 7: Encoding boolean algebra in a hypergraph. 4.2.1 Dependency Formula. Boolean Algebra. Opam supports ‘package formula’ and ‘version for￾mula’, boolean algebra of packages names and package versions respec￾tively [2]. As we have shown (§3.2) we can encode a SAT expression…
Figure 8
Figure 8. Figure 8: A multi-version resolved graph 𝐺. 4.3.1 Concurrent Versions. As discussed in section 2.2.5, Cargo supports multiple versions of packages in a resolved graph. To be precise, it only allows different major version numbers in the semantic versioning scheme [5, 49]. To mod…
Figure 9
Figure 9. Figure 9: A resolution hypergraph where hyperedges are parameterised by features. Extending HyperRes to support features. To start, we define a set of package features for every package, ∀𝑝 ∈ 𝑃, ∃𝐹𝑝 ⊆ 𝐹 and 𝐹 as the set of all possible features. Then, we define a multi-label fun…
Figure 10
Figure 10. Figure 10: A resolution hypergraph where features are encoded as optional dependencies. Encoding the extended formalism in HyperRes. To show that the Hy￾perRes formalism is expressive enough to describe features, we will encode the extended formalism in the HyperRes formalism. F…
Figure 11
Figure 11. Figure 11: A subgraph of the full cross-ecosystem resolved graph querying opam’s [PITH_FULL_IMAGE:figures/full_fig_p021_11.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

60 extracted references · 35 canonical work pages

  1. [1]

    Slackware Package Management

    2012. Slackware Package Management. https://docs.slackware.com/slackware:package_management

    work page 2012

  2. [2]

    OCaml Package Manager, The opam manual

    2013. OCaml Package Manager, The opam manual. https://opam.ocaml.org/doc/Manual.html

    work page 2013

  3. [3]

    Linux Standard Base specification

    2015. Linux Standard Base specification. https://refspecs.linuxfoundation.org/lsb.shtml

    work page 2015

  4. [4]

    The Cargo Book

    2024. The Cargo Book. https://doc.rust-lang.org/cargo/

    work page 2024

  5. [5]

    Cargo Resolver

    2024. Cargo Resolver. https://github.com/rust-lang/cargo/blob/15fbd2f607d4defc87053b8b76bf5038f2483cf4/src/cargo/ core/resolver/mod.rs

    work page 2024

  6. [6]

    Debian Policy Manual: Chapter 5 - Control files and their fields

    2024. Debian Policy Manual: Chapter 5 - Control files and their fields. https://www.debian.org/doc/debian-policy/ch- controlfields.html

    work page 2024

  7. [7]

    Debian Policy Manual: Chapter 7 - Declaring relationships between packages

    2024. Debian Policy Manual: Chapter 7 - Declaring relationships between packages. https://www.debian.org/doc/ debian-policy/ch-relationships.html

    work page 2024

  8. [8]

    Go Modules Reference

    2024. Go Modules Reference. https://go.dev/ref/mod

    work page 2024

Show all 60 references
  1. [9]

    The Haskell Cabal

    2024. The Haskell Cabal. https://www.haskell.org/cabal/

    2024

  2. [10]

    npm Docs Scripts

    2024. npm Docs Scripts. https://docs.npmjs.com/cli/v10/using-npm/scripts

    2024

  3. [11]

    Pietro Abate, Roberto Di Cosmo, Georgios Gousios, and Stefano Zacchiroli. 2020. Dependency Solving Is Still Hard, but We Are Getting Better at It. In2020 IEEE 27th International Conference on Software Analysis, Evolution and Reengineering (SANER). 547–551. doi:10.1109/SANER482...

    2020

  4. [12]

    Pietro Abate, Roberto DiCosmo, Ralf Treinen, and Stefano Zacchiroli. 2011. MPM: a modular package manager. In Proceedings of the 14th International ACM Sigsoft Symposium on Component Based Software Engineering (Boulder, Colorado, USA) (CBSE ’11). Association for Computing Mach...

    2011 doi

  5. [13]

    Jean-François Abramatic, Roberto Di Cosmo, and Stefano Zacchiroli. 2018. Building the universal archive of source code. Commun. ACM 61, 10 (Sept. 2018), 29–31. doi:10.1145/3183558

    2018 doi

  6. [14]

    Snorri Agnarsson and M. S. Krishnamoorthy. 1985. Towards a theory of packages. ACM SIGPLAN Notices 20, 7 (June 1985), 117–130. doi:10.1145/17919.806833

    1985

  7. [15]

    Mahmoud Alfadel, Diego Elias Costa, and Emad Shihab. 2023. Empirical analysis of security vulnerabilities in Python packages. Empirical Software Engineering 28, 3 (March 2023). doi:10.1007/s10664-022-10278-4

    2023 doi

  8. [16]

    Mahmoud Alfadel, Diego Elias Costa, Emad Shihab, and Bram Adams. 2023. On the Discoverability of npm Vulnerabil- ities in Node.js Projects. ACM Trans. Softw. Eng. Methodol. 32, 4, Article 91 (May 2023), 27 pages. doi:10.1145/3571848

    2023 doi

  9. [17]

    Cyrille Artho, Kuniyasu Suzaki, Roberto Di Cosmo, Ralf Treinen, and Stefano Zacchiroli. 2012. Why do software packages conflict?. In 2012 9th IEEE Working Conference on Mining Software Repositories (MSR) . 141–150. doi:10.1109/ MSR.2012.6224274

    2012

  10. [18]

    Benedikt Becker, Nicolas Jeannerod, Claude Marché, Yann Régis-Gianas, Mihaela Sighireanu, and Ralf Treinen. 2022. The CoLiS platform for the analysis of maintainer scripts in Debian software packages. International Journal on Software Tools for Technology Transfer 24, 5 (Sept....

    2022 doi

  11. [19]

    Jon Bentley. 1986. Programming pearls: little languages. Commun. ACM 29, 8 (Aug. 1986), 711–721. doi:10.1145/6424. 315691

    1986 doi

  12. [20]

    Claude Berge. 1970. Graphes et hypergraphes. Dunod, Paris, France

    1970

  13. [21]

    Aarnav M. Bos. 2023. A Review of Attacks Against Language-Based Package Managers. doi:10.48550/ARXIV.2302.08959

    2023 doi arXiv

  14. [22]

    Justin Cappos, Justin Samuel, Scott Baker, and John H. Hartman. 2008. A look in the mirror: attacks on package managers. In Proceedings of the 15th ACM Conference on Computer and Communications Security (Alexandria, Virginia, USA) (CCS ’08). Association for Computing Machinery...

    2008

  15. [23]

    Serena Cofano, Giacomo Benedetti, and Matteo Dell’Amico. 2024. SBOM Generation Tools in the Python Ecosystem: an In-Detail Analysis. doi:10.48550/ARXIV.2409.01214

    2024 doi arXiv

  16. [24]

    Stephen A. Cook. 1971. The complexity of theorem-proving procedures. In Proceedings of the Third Annual ACM Symposium on Theory of Computing (Shaker Heights, Ohio, USA) (STOC ’71). Association for Computing Machinery, New York, NY, USA, 151–158. doi:10.1145/800157.805047

    1971

  17. [25]

    Ludovic Courtès. 2013. Functional package management with guix. arXiv preprint arXiv:1305.4584 (2013)

    2013 arXiv

  18. [26]

    Russ Cox. 2018. Go & Versioning: Minimal Version Selection. https://research.swtch.com/vgo-mvs

    2018

  19. [27]

    Andres Diaz Pace, Antonela Tommasel, and Hernan Ceferino Vazquez. 2024. The JavaScript Package Selection Task: A Comparative Experiment Using an LLM-based Approach. CLEI Electronic Journal 27, 2 (July 2024). doi:10.19153/cleiej. 27.2.4

    2024 doi

  20. [28]

    Eelco Dolstra, Merijn de Jonge, and Eelco Visser. 2004. Nix: A Safe and Policy-Free System for Software Deployment. In Proceedings of the 18th USENIX Conference on System Administration (Atlanta, GA) (LISA ’04). USENIX Association, USA, 79–92

    2004

  21. [29]

    Eelco Dolstra and Andres Löh. 2008. NixOS: a purely functional Linux distribution. In Proceedings of the 13th ACM SIGPLAN International Conference on Functional Programming (Victoria, BC, Canada) (ICFP ’08) . Association for Solving Package Management via Hypergraph Dependency...

    2008

  22. [30]

    Todd Gamblin, Massimiliano Culpo, Gregory Becker, and Sergei Shudler. 2022. Using Answer Set Programming for HPC Dependency Solving. In SC22: International Conference for High Performance Computing, Networking, Storage and Analysis. IEEE, 1–15. doi:10.1109/SC41404.2022.00040

    2022 arXiv

  23. [31]

    Collette, Gregory L

    Todd Gamblin, Matthew LeGendre, Michael R. Collette, Gregory L. Lee, Adam Moody, Bronis R. de Supinski, and Scott Futral. 2015. The Spack package manager: bringing order to HPC software chaos. In Proceedings of the International Conference for High Performance Computing, Netwo...

    2015

  24. [32]

    Martin Gebser, Roland Kaminski, Benjamin Kaufmann, and Torsten Schaub. 2011. Multi-Criteria Optimization in Answer Set Programming. In Technical Communications of the 27th International Conference on Logic Programming (ICLP’11) (Leibniz International Proceedings in Informatics...

    2011 doi

  25. [33]

    Wenbo Guo, Chengwei Liu, Limin Wang, Jiahui Wu, Zhengzi Xu, Cheng Huang, Yong Fang, and Yang Liu. 2024. PackageIntel: Leveraging Large Language Models for Automated Intelligence Extraction in Package Ecosystems. arXiv preprint arXiv:2409.15049 (2024)

    2024

  26. [34]

    Jordan Henkel, Denini Silva, Leopoldo Teixeira, Marcelo d’Amorim, and Thomas Reps. 2021. Shipwright: A Human-in- the-Loop System for Dockerfile Repair. In 2021 IEEE/ACM 43rd International Conference on Software Engineering (ICSE) . 1148–1160. doi:10.1109/ICSE43902.2021.00106

    2021

  27. [35]

    Paul Hudak. 1996. Building domain-specific embedded languages. ACM Comput. Surv. 28, 4es (Dec. 1996), 196–es. doi:10.1145/242224.242477

    1996

  28. [36]

    Alexey Ignatiev, Mikoláš Janota, and Joao Marques-Silva. 2014. Towards efficient optimization in package management systems. In Proceedings of the 36th International Conference on Software Engineering (Hyderabad, India) (ICSE 2014). Association for Computing Machinery, New Yor...

    2014

  29. [37]

    Peter Ivie and Douglas Thain. 2018. Reproducibility in Scientific Computing. ACM Comput. Surv. 51, 3, Article 63 (July 2018), 36 pages. doi:10.1145/3186266

    2018 doi

  30. [38]

    Chris Lamb and Stefano Zacchiroli. 2021. Reproducible Builds: Increasing the Integrity of Software Supply Chains. CoRR abs/2104.06020 (2021). arXiv:2104.06020 https://arxiv.org/abs/2104.06020

    2021 arXiv

  31. [39]

    Nandor Licker and Andrew Rice. 2019. Detecting Incorrect Build Rules. In 2019 IEEE/ACM 41st International Conference on Software Engineering (ICSE) . 1234–1244. doi:10.1109/ICSE.2019.00125

    2019

  32. [40]

    Jiahuei Lin, Haoxiang Zhang, Bram Adams, and Ahmed E. Hassan. 2023. Vulnerability management in Linux distributions: An empirical study on Debian and Fedora. Empirical Software Engineering 28, 2 (Feb. 2023). doi:10.1007/ s10664-022-10267-7

    2023

  33. [41]

    Christian Macho, Fabian Oraze, and Martin Pinzger. 2024. DValidator: An approach for validating dependencies in build configurations. Journal of Systems and Software 209 (2024), 111916. doi:10.1016/j.jss.2023.111916

    2024

  34. [42]

    Fabio Mancinelli, Jaap Boender, Roberto di Cosmo, Jerome Vouillon, Berke Durak, Xavier Leroy, and Ralf Treinen. 2006. Managing the Complexity of Large Free and Open Source Package-Based Software Distributions. In 21st IEEE/ACM International Conference on Automated Software Eng...

    2006 doi

  35. [43]

    André Miranda and João Pimentel. 2018. On the use of package managers by the C++ open-source community. In Proceedings of the 33rd Annual ACM Symposium on Applied Computing (Pau, France) (SAC ’18). Association for Computing Machinery, New York, NY, USA, 1483–1491. doi:10.1145/...

    2018

  36. [44]

    Andrey Mokhov, Neil Mitchell, and Simon Peyton Jones. 2018. Build systems a la carte. In International Conference on Functional Programming (ICFP’18). ACM. https://www.microsoft.com/en-us/research/publication/build-systems-la- carte/

    2018

  37. [45]

    Villa Real, and Michael Homer

    Hisham Muhammad, Lucas C. Villa Real, and Michael Homer. 2019. Taxonomy of Package Management in Programming Languages and Operating Systems. In Proceedings of the 10th Workshop on Programming Languages and Operating Systems (Huntsville, ON, Canada) (PLOS ’19). Association for...

    2019

  38. [46]

    Moses Openja, Forough Majidi, Foutse Khomh, Bhagya Chembakottu, and Heng Li. 2022. Studying the Practices of Deploying Machine Learning Projects on Docker. In Proceedings of the 26th International Conference on Evaluation and Assessment in Software Engineering (Gothenburg, Swe...

    2022

  39. [47]

    Pardis Pashakhanloo, Aravind Machiry, Hyonyoung Choi, Anthony Canino, Kihong Heo, Insup Lee, and Mayur Naik

  40. [48]

    Donald Pinckney, Federico Cassano, Arjun Guha, Jonathan Bell, Massimiliano Culpo, and Todd Gamblin. 2023. Flexible and Optimal Dependency Management via Max-SMT. In 2023 IEEE/ACM 45th International Conference on Software - Gibb et al. Engineering (ICSE). IEEE, 1418–1429. doi:1...

    2023

  41. [49]

    Tom Preston-Werner. 2023. Semantic Versioning 2.0.0. https://semver.org/

    2023

  42. [50]

    Giuseppe Primiero and Jaap Boender. 2018. Negative trust for conflict resolution in software management. In Web Intelligence, Vol. 16. IOS Press, 251–271

    2018

  43. [51]

    Md Fazle Rabbi, Arifa Islam Champa, Costain Nachuma, and Minhaz Fahim Zibran. 2024. SBOM Generation Tools Under Microscope: A Focus on The npm Ecosystem. In Proceedings of the 39th ACM/SIGAPP Symposium on Applied Computing (Avila, Spain) (SAC ’24). Association for Computing Ma...

    2024

  44. [52]

    Kristiina Rahkema and Dietmar Pfahl. 2022. Analysing the Relationship Between Dependency Definition and Updating Practice When Using Third-Party Libraries. In Product-Focused Software Process Improvement, Davide Taibi, Marco Kuhrmann, Tommi Mikkonen, Jil Klünder, and Pekka Abr...

    2022

  45. [53]

    Martin Schwaighofer, Michael Roland, and René Mayrhofer. 2024. Extending Cloud Build Systems to Eliminate Transitive Trust. In ACM Workshop on Software Supply Chain Offensive Research and Ecosystem Defenses (SCORED24) (Salt Lake City, Utah, USA). ACM

    2024

  46. [54]

    Manuel Serrano and Erick Gallesio. 2007. An adaptive package management system for scheme. In Proceedings of the 2007 Symposium on Dynamic Languages (Montreal, Quebec, Canada) (DLS ’07). Association for Computing Machinery, New York, NY, USA, 65–76. doi:10.1145/1297081.1297093

    2007

  47. [55]

    Jacob Stringer, Amjed Tahir, Kelly Blincoe, and Jens Dietrich. 2020. Technical Lag of Dependencies in Major Package Managers. In 2020 27th Asia-Pacific Software Engineering Conference (APSEC) . 228–237. doi:10.1109/APSEC51365.2020. 00031

    2020

  48. [56]

    Ralf Treinen and Stefano Zacchiroli. 2009. Common Upgradeability Description Format (CUDF) 2.0. The Mancoosi project (FP7) 3 (2009). https://www.mancoosi.org/reports/tr3.pdf

    2009

  49. [57]

    Oliveira

    Paulo Trezentos, Inês Lynce, and Arlindo L. Oliveira. 2010. Apt-pbo: solving the software dependency problem using pseudo-boolean optimization. In Proceedings of the 25th IEEE/ACM International Conference on Automated Software Engineering (Antwerp, Belgium) (ASE ’10). Associat...

    2010

  50. [58]

    Chris Tucker, David Shuffelton, Ranjit Jhala, and Sorin Lerner. 2007. Opium: Optimal package install/uninstall manager. In 29th International Conference on Software Engineering (ICSE’07) . IEEE, ACM, Minneapolis, MN, USA, 178–188

    2007

  51. [59]

    Lyuye Zhang, Chengwei Liu, Sen Chen, Zhengzi Xu, Lingling Fan, Lida Zhao, Yiran Zhang, and Yang Liu. 2023. Mitigating Persistence of Open-Source Vulnerabilities in Maven Ecosystem. In 2023 38th IEEE/ACM International Conference on Automated Software Engineering (ASE) . ACM/IEE...

    2023

  52. [2022]

    In Proceedings of the 2022 ACM on Asia Conference on Computer and Communications Security (Nagasaki, Japan) (ASIA CCS ’22)

    PacJam: Securing Dependencies Continuously via Package-Oriented Debloating. In Proceedings of the 2022 ACM on Asia Conference on Computer and Communications Security (Nagasaki, Japan) (ASIA CCS ’22). Association for Computing Machinery, New York, NY, USA, 903–916. doi:10.1145/...

    2022

Pith tools

Reviewed August 7, 2026 · model on record in the stance chip above.