I think you should write this kind of stuff using a different language and output JSON (which nix can read), or perhaps nix code itself. Then run said program on a schedule using your favoured method. Make sure to commit this output file to version control, so you can see when things go wrong.
Using nix to intentionally introduce impurity at eval-time is a bad idea, especially since it won’t be properly tracked in your version control.
Do you mean you want to add this delay for minor version changes between LTS releases (like moving from 6.12 to 6.18 some time after 6.18 is first released)?
kernel.org has an RSS feed, so it seems pretty natural to have a CI/cron script pull that regularly and use whatever logic you like to update your desired version in a data file or tiny nix expression somewhere.
The LTS versions in that feed are all marked with “longterm”, so if I wanted to do something quick and easy I’d consider waiting for 2-4 patch releases instead of a calendar time. Something like “If I see ‘x.y.2 longterm’, switch to version x.y if I’m not on it already” would let you avoid keeping any other state around.
The feed doesn’t keep non-current versions around, so if you wanted precise delay times I think you’d need to record the past release timings yourself. Unless there’s a better data source out there somewhere, which there might be.
Edit to add another “are you sure you want this?” note:
Personally, I probably wouldn’t automate this at all if stability was a big priority, because I’d want to read the release notes beforehand, have eyes on the upgrade as it happens, and know going in that it’s a big kernel bump and not just a routine nix flake update. Having the bump catch me off guard or with unpredictable timing (relative to work schedule, sleep, etc) wouldn’t be worth the disruption for me. YMMV.
I challenge this. It’s a truism you invented. You may have been impacted by a specific bug, I guess, but most of the time people want to avoid updating because change → potential regressions, while no change → no potential regressions.
It’s hard to know what you mean without more details, but I think this is an XY problem, and you don’t really understand your problem, hence your solution doesn’t make sense.
Given that no change means that you probably didn’t introduce new bugs, I’m going to guess you don’t actually mean the word bug.
Is what you’re referring to missing kernel features for your hardware, or some specific software? If so, just setting your kernel version to whichever kernel version introduced the new feature or later is probably what you want. A snippet like this does that:
there were a bunch of repeated kernel regressions a while back, one breaking BTRFS, another breaking Flatpak etc. Since then I use the longterm kernel only
I didnt want to wait for x patch releases as that would depend on the releases existing. Of course you can assume that, but what if there is no need for a patch for a longer time?
But if the default kernel really just is the longterm one, then that is great
Right, sorry, I misread your post. Simply don’t change the kernel version and you get an LTS kernel.
There are usually multiple supported LTS kernels in a particular NixOS release cycle, and the default is the latest LTS kernel when that NixOS release was released, not the latest LTS kernel.
So you could technically sometimes upgrade to a newer kernel and still be on an LTS kernel. Nixpkgs even contains metadata for this, you could write an awkward expression to select the latest LTS kernel. No external scripting required.
That said, doing so will upgrade you to the latest possible kernel every once in a while. If your aim is to avoid regressions, I’d recommend just sticking to the default kernel, and have it automatically upgraded alongside your NixOS upgrades. Then you can just revert the NixOS upgrade if there happen to be regressions exactly when the new NixOS version releases, and you have a one-month window in which you still have full support during which the Linux regressions can be fixed.