news
Categorizing Package Manager Clients in GNU/Linux
-
University of Toronto ☛ Linux distribution packaging should be as declarative as possible
A commentator on my entry on why Debian and RPM (source) packages are complicated suggested looking at Arch Linux packaging, where most of the information is in a single file as more or less a shell script (example). Unfortunately, I'm not a fan of this sort of shell script or shell script like format, ultimately because it's only declarative by convention (although I suspect Arch enforces some of those conventions). One reason that declarative formats are important is that you can analyze and understand what they do without having to execute code. Another reason is that such formats naturally standardize things, which makes it much more likely that any divergence from the standard approach is something that matters, instead of a style difference.
-
Andrew Nesbitt ☛ Categorizing Package Manager Clients
This is the companion to Categorizing Package Registries, focusing on the client side: how package managers resolve dependencies, track versions, run build code, and declare dependencies. The data is also available as CSV. There are gaps; contributions welcome.
Each package manager combines these choices differently. Cargo uses backtracking resolution, generates lockfiles, allows build hooks via build.rs, and uses TOML manifests. Go uses minimal version selection, achieves reproducibility without lockfiles, forbids hooks entirely, and embeds dependencies in go.mod. npm uses deduplication with nesting, generates lockfiles, allows postinstall hooks, and uses JSON. The particular combination shapes the developer experience more than any single choice.