Why is there no rolling `stable` channel?

I’ve always used nixpkgs-unstable but am considering dropping back to a stable channel now, particularly when pinning nixpkgs in individual projects. I’m surprised there’s no nixpkgs-stable though - I would expect this to just point to “the latest stable release channel” (i.e. 19.03 right now, but pointing to 19.09 once that’s released). That way you get stability, but when a stable release is made you get that upgrade by default, rather than having to upgrade release branches everywhere you’ve pinned nixpkgs (you can always drop back to the previous named stable if that causes issues).

Is nixpkgs-unstable not stable enough for you?

Some times it can be difficult to find a channel that works both on darwin and linux when using it as a nix-shell. Other than that it’s working pretty well for me.

1 Like

Jumping between stable branches has backward incompatibilities. I’m fairly certain that’s one of important “stability” aspects, so the “nixpkgs-stable” name might be a bit misleading. When you do such a change on a “production system”, you certainly want to at least read the release notes (and typically do some more testing), which is why I believe it’s usually better to do that step manually (twice a year).

3 Likes

It’s less about stability (things rarely break, which is great). More about frequency of updates. Whenever I nix-channel --update on unstable I need to do a lot of re-downloading (a bit annoying with slow internet), and a whole lot of rebuilding for customisations and other package sets which aren’t in nixpkgs (e.g. lots of ocaml). I assume (untested) there would be fewer rebuilds required on a stable branch. Pretty much everything would need a rebuild every 6 months when the next release came out, but outside that there should be a slower rate of change.

For clarity I wasn’t suggesting this would replace the actual stable release branches, just a meta-branch tracking the “latest” stable branch. On a production system I’d pick a specific release, but for my home system it’d just be like “unstable” but on a larger timescale, with far fewer incremental updates required between release versions.

There may be a better name than “stable” though. “nixos-release”?

1 Like

The stability is okay and given the ability to go back to a previous build if something breaks it is very usable. But I would say that it’s definitively not comparable to a stable branch.
Especially annoying to me is that if something breaks, it takes some time to be fixed. It happened multiple times to me that something broke and I couldn’t rebuild my system (and e.g. add new packages) for several days - until the fix (which could be a git revert or a oneliner) was through hydra. (maybe it would make sense to think about a way to add quickfixes faster to unstable). In my eyes it’s still quite far from a stable release, I see it more like a testing branch :wink:

In other distros the channel switching would typically happen at another level. For example apt-get update notifies the user that there is a new system release available. Once the user is ready to do the upgrade they can do it with a command that switches the channel for them. We could implement something similar in the nixos-rebuild command to check the list of releases and compare it with the current system. I think it’s better than creating yet another channel as users are already confused by the current set of options.

I stopped using nix-channel for that reason. Once you know how to do it, it’s easier to use a git checkout and rebase your changes on top of the tracked channel. It removes the hard dependency for things to be merged or go through the build pipeline before they can be used which is great. I am no longer frustrated if things move slowly :slight_smile:

  1. set export NIX_PATH=nixpkgs=path/to/nixpkgs-checkout:nixos-config=machines/my-machine/configuration.nix using direnv or a wrapper script that then invokes nixos-rebuild.

  2. to use the same nixpkgs checkout everywhere, add the following in the nixos configuration:

{ pkgs, ... }:
{
  nix.nixPath = [ "nixpkgs=${toString pkgs.path}" ];
}
  1. remove all the channels [sudo] nix-channel --remove nixos
4 Likes

This is the reason why I now follow 3 channels simultaneously. Most of my software come from nixos-stable, but since some fixes take a long time to land there, I also have some software from nixos-unstable. Then there are packages which broke when I switched from 18.09 to 19.03, so I have few packages from the old stable as well

The main point of the waiting is to avoid such breakages. The channel only updates after a set of tests passes.

Yeah that’s obvious to me. It’s nonetheless annoying IF something gets through :wink:

As I mentioned, it may make sense to be able to mark a PR/commit as “quickfix” or “important” so that it gets tested more quickly. But I do also understand that it may not be something we would want to have, as it can be really hard to tell/define when a commit is “important enough” to add this label.

Absolutely right. Unfortunately, having a -stable alias for the channel is likely to make people think “Oh, stable? I want my production servers to be stable”, then suddenly their services are hosed after the next release upgrade. That’s why I think it’s a bad idea to have the alias.

What do you mean by fewer incremental updates, and what benefit do you get from it?

1 Like

Let’s say some package (say, libfoo) is updated every month on average in the unstable channel. That means I have to re-download or re-build all its transitive dependencies every month. On a stable channel, that would go closer to every 6 months (aside from security updates).

That’d make me less reluctant to update, because right now updating a channel means waiting around for ages while things rebuild or re-download. This can be hours depending on what’s changed, so it’s not something I want to do every few days. If that update was due to a minor feature in a library that I don’t know about or use, it doesn’t feel very worthwhile. If it’s due to a security update or a every-6-month feature jump then that’s much more reasonable.

I’m sure this isn’t a normal case, but I have a sizeable stack of stuff which is not in nixpkgs/hydra, so “just use a binary cache” won’t speed anything up.

1 Like

Yes, currently the updates can consume a lot – usually I’d say on the order of gigabytes per month of both network and drive, for a desktop machine at least (servers might have much smaller closures).

If you’re looking for a stable channel that only updates every ~6 months, modulo bugfixes and security backports, isn’t that precisely what the nixos-YY-MM channels are?