A Protocol for Package Management
15 points by calvin
15 points by calvin
From the title I expected this to be about package managers like Pacman, apt-get, dnf, etc. It's actually about dependency management tools like rubygems and Cargo.
Yes, it’s surprising to not see deb, or rpm, or even Linux containers or GitHub Actions or Helm charts if you want to take a broader view, even winget (gasp) for that matter. That perspective would enrich some parts of the proposal. “Depends” relationships are insufficient to model real world package ecosystems. What do we do with APT’s “Breaks” or “Provides”? While the scale of the problem became evident with npm and mvn, one can’t ignore that Debian repositories and PPAs were in the news 15 years ago when some repo owners pushed base packages (IIRC for protestware purposes like changing wallpapers) even though no one coined dependency confusion back then.
That said this is a remarkable exercise by Andrew because abstractions are indeed hard. Those that have done that work successfully (like purl, mentioned in the article, and perhaps Dependency Track, OSV, Repology, Pulp, etc., and I’m sure commercial solutions as well) have abstracted only the parts of the domain they need. I think progress can be made in all the problem areas the proposal seeks to enable despite the lack of a universal resolver and unified semantics. Typosquatting defenses don’t need every ecosystem to agree on implementation. That said, few systems use a single ecosystem and if they do, their supply chain doesn’t use a single ecosystem, so at some point someone might want to compare and contrast package manager approaches and this might be a helpful, fresh framework in those situations.