A New Rust Packaging Model
18 points by FedericoSchonborn
18 points by FedericoSchonborn
I was lurking on the Guix repository (hosted on Codeberg!) and noticed this was recently merged into the main branch :)
This was an interesting read. It’s interesting how new distributions are challenging the traditional Linux distribution models with dynamic linking, etc. (speaking from quasitotal lack of knowledge).
Containers, immutable distributions, declarative distros, etc. I suspect mainstream Linux distributions will change significantly in the next years, and I’m quite curious about where we will end up. I think the most significant change in recent times was systemd, but really that did not affect packaging.
I’m itching for something Nix like to land, with clear/easy documentation and some degree of LTS.
It’s interesting how new distributions are challenging the traditional Linux distribution models with dynamic linking, etc. (speaking from quasitotal lack of knowledge).
Fundamentally it’s more that programming language implementations are moving away from C/C++ style system wide dependencies managed by the system, and instead moving towards static dependencies that are built into the program and managed by the developer.
There are benefits and tradeoffs to both solutions (ability to optimize, disk space, memory, etc) but fundamentally distributions are used to the former, and package managers are designed around it.
I’m not very familiar with Guix, but coming from a Nix perspective.. this seems like something that’s largely inconsequential change for distro packagers (since you already expect the tree to build, and build trees are rarely similar enough in practice between different workspaces that you’re likely to benefit much from cross-workspace dependency caching), but will be absolutely devastating for application developers (since you’d now go from incrementally recompiling the leaf crate in a few seconds, to recompiling the whole workspace’s dependency tree in a few minutes).
At $oldjob I ended up migrating our dev builds from dockerfiles to crate2nix for the opposite reason; it was the only way to keep our build times anywhere near sane!
Disclaimer: I too come from a Nix perspective, but have used/contributed to Guix a little too.
this seems like something that’s largely inconsequential change for distro packagers (since you already expect the tree to build, and build trees are rarely similar enough in practice between different workspaces that you’re likely to benefit much from cross-workspace dependency caching)
My understanding is that Guix packagers want more control over what goes into their builds: being able to swap crates, or delete non-free crates. From the bottom of the post it looks like packagers/admins can centrally prohibit or swap particular crates.
The post briefly discusses crate2guix which looks similar to crate2nix.
but will be absolutely devastating for application developers (since you’d now go from incrementally recompiling the leaf crate in a few seconds, to recompiling the whole workspace’s dependency tree in a few minutes)
The post mentions that Guix’s Rust builds incurs the cost of per-crate builds + per-applivation (and with no build caching from the per-crate). So this design is at least an improvement over the status quo.