Could someone tell me what’s the difference between nixos-unstable, nixos-unstable-small, and nixpkgs-unstable channels? And why isn’t there a programs.sqlite exists in nixpkgs-unstable?
1 Like
All three of them are based on the nixpkgs master branch. Each of them advance only if all of their tests are passing. The only difference is the list of tests that each of them have. By convention the -small postfix is based on the the same test suite but with less tests in them so they advance faster.
See https://howoldis.herokuapp.com/ for more details.
2 Likes
Thank you all for your kind explanation!
I’m confused, I thought that the -small channel was a smaller closure that is also built on a tighter schedule, so not all binaries that you would want would be there?
Compare the build details of nixos-small with those of nixos, the closure sizes are 2.9GB and 14.7GB, respectively.
so am I correct in thinking that if you want nodejs and you use the nixos-small channel, it will build it from scratch?
2 Likes
I may be wrong, but my understanding is that the -small channel advances more often and therefore you may build stuff from scratch that wasn’t part of the -small closure, but that a substitute may be available for the package anyway after the regular channel has successfully built and advanced (assuming it contains the same derivation).
Right - so most of the time, if you upgrade the channel and rebuild, the exact derivation you’d like hasn’t been built yet and therefore would have to be built on-machine.
So the -small channel is for people with very basic needs or lots of build capacity 
Only if the derivation you want was updated recently. If updating the channel updates the derivation, but you only update your channels once a week, then maybe there will be a substitute available anyway.
My vague understanding was the -small channel tended to omit things like GUI packages, so it’s useful on servers.
Indeed it seems so - and it even includes nodejs apparently, but not the v10 version in 18.03 
. I’ll PR that.
1 Like
fwiw on my ~25-30 machine nixops network which runs on -small I can’t remember the last time something was compiled on a deploy. I know at least several of those servers run nodejs.
1 Like
Yes, IIRC I believe the main motivation was to have fast security fixes for servers, even in cases when mass rebuilds are needed (e.g. patching glibc).
I’ll try to explain a bit. The binary cache is shared for everything, channels or not. That’s why you may still get binaries for other packages. Even on bigger channels you only have guarantees for closure in the tested jobset (which arguably isn’t too large so far), because when some other build fails, that will not block the channel from updating (but the big channel will still wait for all builds to finish).
2 Likes
If it’s really that small, maybe we should update the docs. Right now it implies that it mostly just omits GUI applications. It says more rebuilds may be necessary, but doesn’t tell me that I might end up rebuilding e.g. glibc.
The job lists are visible, and I’d call it really small, compared to the rest, even if I consider transitive dependencies. Hydra - nixos:unstable-small
Documentation about the scope of the channels basically doesn’t exist, I believe, at least under the nixos.org domain (say the manuals or such), so I suppose it would be nice to find some place for it and document the state. (I have no particular ideas ATM.)
NixOS 23.11 manual | Nix & NixOS is specifically the documentation I’m thinking about.
- Small channels , such as
nixos-19.03-smallornixos-unstable-small. These are identical to the stable and unstable channels described above, except that they contain fewer binary packages. This means they get updated faster than the regular channels (for instance, when a critical security patch is committed to NixOS’s source tree), but may require more packages to be built from source than usual. They’re mostly intended for server environments and as such contain few GUI applications.
1 Like