linux_hardened: only provide latest LTS and latest stable version #432561
Conversation
This serves to differentiate between a kernel that is an LTS release and one that is merely a regular "stable" release.
(cherry picked from commit eb85811eb974acaf22cd0602730c034f0d699586)
These are all LTS kernels (cherry picked from commit 1170dcdc89b2c640c449d215e8ba42fdb1b0e63b)
These are based on 6.6.y (cherry picked from commit d44a5499d71bd03603377ea1b7905ee6ac746be6)
As proposed in NixOS#346018 (not closing the ticket, this affects other variants as well). The packaging for hardened is in a pretty sad state: it was lagging several patch-releases behind and nobody seems to care. The update script aged poorly: the automatic removal was flat-out broken, several type annotations are plain wrong (`list[int] != packaging.Version`). This patch is an attempt to reduce the scope for the maintainer team drastically to provide _some_ maintenance again by only packaging latest LTS and latest stable. Also, remove the top-level attributes for this. I still don't see any compelling reason to give hardly used flavours that special treatment.
90418ff to
10af2ee
Compare
|
For the 6.15 init its missing some manual intervention (needs its attribute added) I'm not opposed (I only use the latest after all and latest LTS + latest stable seems reasonable) |
|
NVM, noticed that adding the 6.15 attributes was done in this commit: 10af2ee |
There was a problem hiding this comment.
Sorry about the state of the update script. I believe it type‐checked when I first wrote it, but it’s been many years.
As I said before, this seems like a fine change to me in principle. I haven’t looked at the update script changes in depth. I did mention in previous discussions that “the latest LTS/stable release” and “the latest LTS/stable release that there are hardened patches for” are not necessarily the same, although I believe that back in the day the lag time was only on the order of days. I am not sure if that is still the case, or if the approach here handles it (I guess it seems like it would mostly be manual, which seems fine?).
Apologies for the maintenance burden caused by these downstream kernels. I think they’re higher‐value than some other variants we carry, but updates being broken is scary…
If you anticipate further fuss being caused by them, then I am personally okay if you just wanted to drop them entirely, since I realize that I have done almost nothing to keep them in a good state over the years.
| @@ -1197,6 +1197,22 @@ mapAliases { | |||
| ''; | |||
| linux_latest_hardened = linuxPackages_latest_hardened; | |||
|
|
|||
| # Added 2025-08-10 | |||
| linuxPackages_hardened = linuxKernel.packages.linux_hardened; | |||
There was a problem hiding this comment.
I think this will break nixos/modules/profiles/hardened.nix when !enableAliases; that should probably be fixed.
Another alternative would be to just remove the profile, which is probably overdue at this point…
| @@ -40,6 +40,7 @@ buildLinux ( | |||
| in | |||
| [ rt-patch ] ++ kernelPatches; | |||
|
|
|||
| isLTS = true; | |||
There was a problem hiding this comment.
nit: whitespace (feel free to ignore)
|
I would oppose the complete removal and would prefer to keep at least latest LTS + latest stable. |
To actually obtain the metadata about what's an LTS, I rebased most of @Atemu's #361573.
We should really backport this part btw, otherwise automatic backports of kernel patch-releases will be broken for the rest of 25.05.
As proposed in #346018 (not closing the ticket, this affects other
variants as well).
The packaging for hardened is in a pretty sad state: it was lagging
several patch-releases behind and nobody seems to care. The update
script aged poorly: the automatic removal was flat-out broken, several
type annotations are plain wrong (
list[int] != packaging.Version).This patch is an attempt to reduce the scope for the maintainer team
drastically to provide some maintenance again by only packaging latest
LTS and latest stable.
Also, remove the top-level attributes for this. I still don't see any
compelling reason to give hardly used flavours that special treatment.
Things done
passthru.tests.nixpkgs-reviewon this PR. See nixpkgs-review usage../result/bin/.Add a 👍 reaction to pull requests you find important.