Discuss how many versions of Kernel flavors to keep

[Ma27]

This was originally triggered by #343751 (comment)

linux_5_4_hardened was broken and the question is basically whether we even need numerous Linux hardened versions. There aren't many users anyways (if any given that nobody complained when the update script was broken and there weren't updates for months).

The idea is to drop all except latest and last longterm kernel.

Upon writing this, I'm wondering if we want to do the same for other variants such as rt kernels.

cc @alyssais @emilazy @fabianhjr @K900

---

Add a 👍 reaction to issues you find important.

[Frontear]

I'm in agreement for removal. Kernel flavours should really only be provided for the latest and/or lts branches. Anything beyond that just doesnt seem practical to support.

Perhaps we could offer better documented tooling that provides users with the ability to bring forth a custom kernel variant fairly easily. I don't really think this is an extremely popular option though, given like you said, nobody noticed a derivation that was broken for months.

[teto]

no need to support the world indeed. If there is demand, it can be done in NURR, nix-community and so on.

[fabianhjr]

for other variants such as rt kernels

My understanding is that RT kernels probably going away since the RT patches were mainlined in 6.12.

https://www.phoronix.com/review/linux-612-features

[fabianhjr]

due to the automation I think it is better to keep all lts versions but only build on hydra/cache and actively expect to maintain latest stable + latest lts on all kernel variants.

[fabianhjr]

@Frontear

the latest and/or lts branches.

That is currently the case, the proposal of @Ma27 is to drop all but the latest LTS.

[Frontear]

@Frontear

the latest and/or lts branches.

That is currently the case, the proposal of @Ma27 is to drop all but the latest LTS.

Ah okay I misunderstood. Still in support though! If demand is strong, then offering tooling to provide custom derivations would be preferred than having nixpkgs maintain the burden of keeping them around.

[fabianhjr]

Btw, just on procedure side should probably get @NixOS/release-engineers involved (specially since the first freeze is about 10 days away)

[fabianhjr]

Ok, from looking at current nixpkgs recurseIntoAttrs is used to evaluate all of the packages of a kernel. (same mechanism as python3[minor]Packages)

Currently RT kernels aren't recursed into and I would propose to do the same for all the variants except latest stable and latest lts.

Will open a PR as draft with that specific change.

[K900]

I think maybe having a few LTS releases is helpful for getting a rough idea of when something broke, but I am not opposed to removing them in general.

[Ma27]

Kernel flavours should really only be provided for the latest and/or lts branches

I don't mind for releases from the mainline kernel: these haven't caused too much trouble IIRC, so I'm indifferent on that one.

I think maybe having a few LTS releases is helpful for getting a rough idea of when something broke

I agree for mainline, but I mean, the hardened 5.4 has been broken for a while and so far nobody cared (and I have the impression that nobody from the kernel team is currently willing to do that - which is totally OK!).

[emilazy]

I think that for the hardened kernels it would be totally okay to just completely drop the versions other than latest LTS and latest stable rather than not recursing into them. But I guess that would need changes to the update script?

[Ma27]

In theory it would be sufficient to just remove the stuff from linux-kernels, but it's kinda ugly to have an update-script generating commits for packages that don't exist.

[Ma27]

Getting back to this I think that

I think maybe having a few LTS releases is helpful for getting a rough idea of when something broke

is not sufficient for the hardened (i.e. non-mainline) flavour that nobody seems to be really interested to maintain, let alone non-latest/LTS versions.

The python3 thing is somewhat a different situation because requiring an older interpreter is a more common use-cases and RT kernels were just older than our "no more additional flavours"-rule, but there's a clear path of those disappearing.

I haven't read about anybody particularly caring for non-LTS/non-latest hardened kernel. So I think I agree with @emilazy on just killing them. And it might be good to revisit the updater script anyways, I've seen it add commits for kernel minors we removed from nixpkgs already.

Does anybody oppose this proposal? Otherwise I'll file a PR for that soonish.

[fabianhjr]

I've seen it add commits for kernel minors we removed from nixpkgs already.

It uses the mainline json so if it isn't removed there it will keep adding them back

[emilazy]

I am not sure if we have a programmatic way of telling which kernel is the latest LTS. It would be easy to adapt the script to only maintain the latest LTS kernel that has patches and the latest stable kernel that has patches if we have a reliable source of that data it can read from.

Sorry for the neglect the hardened kernels and profile have seen. I am still interested in making them a good option at some point, but other things have taken priority, and I don’t want them to cause a burden on the kernel maintainers. I am okay with whatever kernel maintainers want to reduce the hassle here. If there’s a concrete task with the update script that needs doing I can look into doing it. I wouldn’t object strongly to just dropping the hardened kernels entirely either if they are causing too many problems, although it would be nice in that case if the door was open to them returning at a later date if I or someone else can actually properly take responsibility for them.

[emilazy]

I am not sure if we have a programmatic way of telling which kernel is the latest LTS. It would be easy to adapt the script to only maintain the latest LTS kernel that has patches and the latest stable kernel that has patches if we have a reliable source of that data it can read from.

To clarify: Although the linux-hardened upstream is pretty good at releasing patches quickly, they’re not perfect at it. So if we only carried the latest stable and latest LTS we might end up with hardened kernels disappearing. What would make the most sense is “latest stable with hardened patches available” and “latest LTS with hardened patches available”. For instance, if mainline.json contained a flag representing which versions are LTS, it would be easy to do this.

[Ma27]

It uses the mainline json so if it isn't removed there it will keep adding them back

Sure, but for the "only LTS & latest"-approach we'll just pick two from kernels-org.json which should fix the underlying issue of obsolete entries in there.

I am not sure if we have a programmatic way of telling which kernel is the latest LTS

I don't think there is, at least on eval time. But I think it's perfectly fine to either specify the latest LTS or to just use the default pkgs.linux (which is a recent LTS).