How does this work in practice with it's "rolling release" nature? Can you designate specific package versions for all your dependencies? Like having a very new openssl and an older zlib version?
With complex software, just grabbing the latest version of every dependency will lead to broken builds (or ones that only work on x64 but are broken on other platforms)
Last I looked at GUIX (which I guess is similar) you are tied to a release "version" of the package-manager with whatever package version it comes with. But maybe I misunderstood
> Last I looked at GUIX (which I guess is similar) you are tied to a release "version" of the package-manager with whatever package version it comes with. But maybe I misunderstood
Guix has Inferiors [0] for this nowadays.
There's also a lighter-weight but less robust approach: define a new package inheriting the package in question, changing only the version number and source URI.
> How does this work in practice with it's "rolling release" nature? Can you designate specific package versions for all your dependencies? Like having a very new openssl and an older zlib version?
NixOS (the distribution) is not actually rolling: it has stable channels that are released twice a year, and an "unstable" channel that normally updates every few days (depends when all tests passed). You could call the latter "rolling", but it's a bit different compared to actually rolling distributions like Arch Linux.
> Can you designate specific package versions for all your dependencies? Like having a very new openssl and an older zlib version?
Normally only the last version is packaged, but you can change the version of the package and install multiple versions of the same library without conflicts.
Some big libraries have multiple branches for backward compatibility (eg. boost175, boost174, openssl_1_1), for the others you have to override the package (it's pretty easy, but you'll likely lose the binary cache).
> With complex software, just grabbing the latest version of every dependency will lead to broken builds (or ones that only work on x64 but are broken on other platforms)
If you really need that kind of stability, a common solution is to pin the version of the whole Nixpkgs. Something a little less drastic is simply using the stable channel, which only receives security updates.
> Last I looked at GUIX (which I guess is similar) you are tied to a release "version" of the package-manager with whatever package version it comes with. But maybe I misunderstood
I'm not familiar with Guix, but I think you can do what I described above with it too.
I mixed things up a bit. Guix doesn't have a stable channel but Nix does. Twice a year sounds quite fast - but maybe that's just what I'm used to from Ubuntu LTS. I can't imagine being a package maintainer and having to deal with build issues that often (I guess it only targets x64 so it's not too bad)
> If you really need that kind of stability
I guess I don't really 'need' it .. but I just rather my system not be constantly updating and changing under me.
Looks like you have run stable and add unstable packages as needed:
You may be interested by Spack [1] if you're fine with linux / macos, it gives you all the versions, and you can specify lower and upper bounds for dependencies. Not only that, it also gives you conditional dependencies through variants, compilers, architectures, etc. Also it allows you to compile everything from sources for your micro architecture.
With complex software, just grabbing the latest version of every dependency will lead to broken builds (or ones that only work on x64 but are broken on other platforms)
Last I looked at GUIX (which I guess is similar) you are tied to a release "version" of the package-manager with whatever package version it comes with. But maybe I misunderstood