4 ms·
As great as Nix is, a security update to something like glibc will necessitate a rebuild of the entire universe as a necessary consequence of its "immutable, ha
by endgame 3y ago
As great as Nix is, a security update to something like glibc will necessitate a rebuild of the entire universe as a necessary consequence of its "immutable, hashed inputs" model. Guix has a feature called "grafts" that avoids some of this pain, but compromises the purity of the functional packaging model to do so.
- SkyMarshal 3y agoBut Nix rebuilds are cheap and fast, what’s the problem?
- ochoseis 3y agoPlus they can be easily cached so you only ever have to do it once, and the result is available to your whole fleet.
- nbpname 3y agoGrafting is indeed a good solution for fast security updates, except that the way this is implemented in Guix depends on the maintainer of each package. This is indeed better than Nix which relies on asking every user to replace the dependencies. A few years ago, I made a proposal to have some automatic grafting mechanism: https://github.com/NixOS/nixpkgs/pull/10851 https://github.com/NixOS/nixpkgs/pull/10851 This would automagically work by simply maintaining 2 trees of Nixpkgs, one with the cherry-picked security updates, and one which matches the latest set of cached packages. This way one can fully benefit from the cached packages while having the ability to replaces with the latest security patches they want to import without building the world. Unfortunately, rewritting Nixpkgs to fit the requirements needed to have the automagic mechanism is a huge project, especially given the activity of Nixpkgs. Maintaining a fork of Nixpkgs which stays up-to-date while changing its inner working cannot be held by a single person. My hopes would be to push this to the Nixpkgs Architecture Team, while preventing them from doing mistakes by inserting extra complexity while making this work more challenging.