Dependency Solving Is Still Hard, but We Are Getting Better at It
Pietro Abate, Roberto Di Cosmo (UP, Inria, DGD-I), Georgios Gousios, (TU Delft), Stefano Zacchiroli (UP, Inria, DGD-I)

TL;DR
Dependency solving remains computationally hard, but recent advances like SAT-based techniques are improving capabilities in package managers, though many approaches still face adoption challenges.
Contribution
The paper reviews the evolution of dependency solving methods, highlighting the adoption of SAT-based techniques and analyzing challenges in integrating these methods into package managers.
Findings
SAT-based dependency solving is increasingly adopted in package managers.
Many package managers still do not outsource dependency solving to reusable components.
Emerging challenges include scalability and integration of advanced solving techniques.
Abstract
Dependency solving is a hard (NP-complete) problem in all non-trivial component models due to either mutually incompatible versions of the same packages or explicitly declared package conflicts. As such, software upgrade planning needs to rely on highly specialized dependency solvers, lest falling into pitfalls such as incompleteness-a combination of package versions that satisfy dependency constraints does exist, but the package manager is unable to find it. In this paper we look back at proposals from dependency solving research dating back a few years. Specifically, we review the idea of treating dependency solving as a separate concern in package manager implementations, relying on generic dependency solvers based on tried and tested techniques such as SAT solving, PBO, MILP, etc. By conducting a census of dependency solving capabilities in state-of-the-art package managers we…
Peer Reviews
No public reviews on file for this paper yet. If you reviewed it on a platform where reviews are public (OpenReview, ICLR, NeurIPS, ICML), you can paste yours below so the community can read it here.
Videos
No videos yet. Explain this paper in a talk, walkthrough, or lecture? Add one.
