Even though I consider doing large upgrade steps “safe” as you usually can just reboot into the earlier version, I’d always suggest to do it incrementally, as it reduces the count of possible problems introduced at once.
And to install any package from any channel you can use the technique as described in the wiki: FAQ - NixOS Wiki
The very same technique works for any channel combination or even multiple channels than just current stable and unstable.
If you are on flakes, things are a bit different. Also in general, if you want to change package versions of things installed via a module, then there are sometimes *.package options you can easily set, and sometimes you have to use overlays to achive the goal, as no package option is provided by the module.
Surely, I am greatly confused about a lot of things
right, I will do it.
that is what I am doing now, but it I do not know how to find a reliable (working) sha/version for a package… I tried Nix package versions , but still has five weeks intervals.
meaning that I could even mix very old channels or anything else…?
I did not look into flakes yet, it seems that would add complexity to my (WIP) configuration.
this looks promising, do you have any link to examples? Or could you suggest a search string that I can use to get to the point (basically, I am confused on how to be sure if a package provides or not a package option)?
I use overlays for a couple packages, so I should be able to figure this out.
Mixing too old stuff with too new might cause some trouble. I think it was around March/April of 2020, when using the stable channel and the unstable channel at the same time could cause font-config issues due to the font-config version used in either had different and incompatible file format for the database.
Another issue I remember was, that there has been a short period of time where mixing caused issued with the glibc, but I do not remember the details as I was not affected.
In my experience a lot of complexity for managing channels or IFD for pinned tarballs from GitHub with certain commits of nixpkgs can actually be removed by using flakes, as the goal is to have them defined at a single location, the flakes inputs attribute.
Though yes, flakes require some additional effort for re-learning some ways that just work differently there.
Though if you go already accustomed to the way how the newer nix commands work (those with subcommands, rather than a hyphen) then you’ll either need to learn flakes and the new-new commands or switch back to the hyphenated commands for everything.
nix.package option is an example. And it seems as if there are 330 options like that (on 21.05):
Fascinating how generations are not ‘compartmentalized’ among them… I am not tinkering with the installation, but I had a couple issues in the last (current at the moment of the issue) generation that affected several previous generations (but not all). Once I solved the issue only because I am very cautious about garbage collection