I know its called nixpkgs-unstable but its needed to not have packages that are months old. I’ve been waiting days to rebuild my nix darwin configuration and its due to package build errors that with issues on the nixpkgs github that have been open for weeks. Why couldn’t Nix just use the last known working versions of packages or dependencies? Or why are new package versions pushed and not pulled back if there are build errors?
That’s the kind of suggestion that sounds easy, but is quite difficult to implement in practice. It would drastically change so many aspects of how nixpkgs works it isn’t really feasible to contemplate.
Firstly, it isn’t just versions of a package. It’s the versions of its entire dependency closure. Changes to any dependency can change the functionality of a given package.
Secondly, the old versions aren’t in that version of nixpkgs. The whole model assumes you build from one version of nixpkgs. This requires re-architecting the whole concept of how nixpkgs is pulled and used, or extending it to include the entire version history of every package somehow, including deterministic dependency version picking…
I’m sure there’s more, but that should give a hint as to why this isn’t really workable.
7 Likes
unstable could fall back specifically to the latest stable … I’m not sure it’s a good idea though. In addition to requiring work, in would leave us with less incentive to test unstable. We might end up having stable, unstable and a testing channel all in active use, like Debian.
That would still mean changing how you even use nixpkgs. You’d need two copies of nixpkgs, and some way for nixpkgs to invoke fallback to the other one. It’s a big change to the interface.
Falling back to last stable would mean, that packages would suddenly downgrade, if they are available at all.
1 Like
Totally agree with you both.
That’s okay. We can use system.stateVersion to automatically rewrite each package’s config when that happens just kidding
Well, the problem is that lib also often contains breaking changes on unstable, so reverting to stable would completely break people’s nix evaluation, even if packages didn’t disappear. You would never even get to running the code that stateVersion could be used by, you fail before it starts building.
The underlying problem is that nixpkgs is a big ol’ monorepo where far too many things are tightly coupled. In a hypothetical world where we have a separate nixpkgs/core, nixpkgs/lib, nixpkgs/community and so on, the full-closure failures could be solved in the first place (through more thorough CI on guaranteed subsets), and even compatible rollbacks might be possible to some degree. It’d go a good way towards improving the supply chain security problems, too. But I don’t see it happening anytime soon.
3 Likes
We have about 300 maintainers who are active at any given time and 120K+ packages to maintain. If there are packages you want kept current, and if you have the skills, why not become a maintainer?
1 Like
I think flakes offer a good way of sidestepping some of the channel issues as well, no?
You can have the same issue with flakes: run nix flake update and if something in there doesn’t build, you can’t finish nixos-rebuild/darwin-rebuild.
If you’re keeping that all in git, you could potentially revert one or more of the flake.lock changes to keep the previously-working code.
Honestly, this isn’t a frequent problem. If it is for you, consider trimming the main system definition and using specialized packages in their own projects (for example, using devenv)