Hi Nix folks, I’m an arch user and Nix is a very interesting project for me. One thought just came to my mind: has anyone tried to create Nix binary distribution, say, bleeding-edge rolling release one?
I understand that main feature of Nix is the ability for packages to have their own arbitrary dependency tree. I do understand that is also the main direction for further research, like making packages content-addressed, reproducible and so on.
But that doesn’t forbid you to have a Nix-based “traditional style” binary distribution, where all packages are coherent, i.e., use the same version of a given system library. That would allow for packages to be distributed in binary form, like traditional distros do, without the need for content-addressability. Has anyone tried to do that?
Note that except for fixed-output derivations, Nix store paths of built derivations are not content-addressable. They are addressed by a hash of the derivation + package name (which typically also contains the version).
Note that packages are also distributed in binary form. If an output path available through the/a binary cache, a precompiled binary is downloaded…
Unless you override packages this is, by and large, the case. E.g. virtually all packages use the same glibc version on Linux within a given revision of
nixpkgs. Of course, since Nix allows parallel installs of different versions packages, some packages may explicitly use different version of a package (e.g. because it doesn’t build with the latest version).
If you want bleeding-edge go for NixOS unstable. The good thing, if anything breaks you can just rollback instead of having to use a recovery usb stick like I had to do every once in a while with Arch.
Thanks a lot. I get it, packages are largely coherent within a release. Still, it’s a binary cache and not a package repository. A binary cache as I understand is just a way to get a tarball by its hash. I probably cannot see all the consequences from this, but I think that getting a package using binary cache involves a significant part of the building machinery: resolving dependencies dynamically, etc.
The dependency resolving in nix is actually quite stupid (in the sense of simple) compared to other package manager. It does not have a concept of version constraint. Packages are built once against its build dependency and every string reference to a package that is found by nix in the package installation directory will become its runtime dependency. So runtime dependencies that need to be downloaded from the cache are actually determined statically.
I actually came across this Static Nix: a command-line swiss army knife
Looks like there was a maintained fork to try and create a static distribution so that you can easily seed Nix installations.
That’s not quite right. The binary cache distributes the build results (yes they are hash addressed, but by the input hash, i.e. the package specification).
The nix channels are a binary distribution. Its just a little bit better than that, since you can freely modify packages and build them from source if you want. But if you do not modify anything and use a channel, you will not have to rebuild anything.