[Nix-dev] end-of-life kernels

[Mathijs Kwik]

On Sun, Nov 18, 2012 at 8:14 PM, Lluís Batlle i Rossell
<viric at viric.name> wrote:
> On Sun, Nov 18, 2012 at 11:17:57AM +0100, Mathijs Kwik wrote:
>> Is anyone still using linux 2.6.15 or 2.6.35 or 3.1 or 3.3 or 3.5 ?
>> If not, we should probably take them out, as they won't be receiving
>> updates any more.
>
> We still use the kernel headers from 2.6.35. As for 2.6.15 or anything <.35 ...
> I doubt the nixpkgs userland will completely work with 2.6.35 headers, so I
> guess it can be removed easily.
>
>> As for 2.6.35, a downgrade to 2.6.34 or 2.6.32 would do the trick,
>> they receive long-time support.
>> 2.6.32 is in nixpkgs already, 2.6.34 isn't. Just having 1 long-term
>> 2.6 around (2.6.32) would clear up nixos kernel stuff nicely.
>
> I'd fix that in the next stdenv upgrade. Or does anybody see a hurry?

Not really, I think most nixos users are well aware of the statuses of
their kernels.
But keeping unmaintained software with known (security)issues around
might not be the wisest choice.
Besides, for almost all other software, we try to wield out versions
that aren't used and try to keep only 1.
Of course kernels are always a somewhat odd piece of software, so it's
not strange we keep many versions of them around. But as they are
marked EndOfLife upstream, we should consider removing them too.
I think stdenv-upgrades is suitable for changing the default kernel
version or upgrading headers, not for removing cruft.

I would think we just need a few versions at any time:
- one 2.6  (probably 2.6.32 or 2.6.34)
- 3.2 is our current default
- latest and pre-latest stable (currently 3.4 and 3.6)
- bleeding edge

Indeed I didn't think about 2.6.35 being our current headers, so
indeed we should keep 2.6.35 until stdenv-upgrades.

I propose removing these versions soon (not wait for stdenv:
- 2.6.15 (probably not working because of headers version)
- 2.6.32 (still maintained, but we already have 2.6.35 for 2.6)
- 3.0 (still maintained, but I don't see much use for it)
- 3.1 (end of life)
- 3.3 (end of life)
- 3.5 (end of life)

Then with stdenv-upgrades we can:
- upgrade default kernel to 3.4 or 3.6
- upgrade default headers to 3.2 (oldest 3.x kernel still supported by then)
- decide which 2.6 version we want to have (2.6.32 or 2.6.34)
- introduce headers-2.6 for that same version

I understand that having 2 header versions available would cause every
package to rebuild when you switch, but at least it allows keeping a
2.6 kernel around. Currently 2.6.15 is probably broken indeed because
of the newer default headers.
And as using an old 2.6 kernel is probably only useful for very small
builds for specialized hardware anyway, rebuilding everything for that
does not need to be an issue.

Anyway, I'm not saying we should make these changes tomorrow, but
probably in a few weeks time.
It's clear some people are stuck on 3.5 because of wifi issues, so
they need some time to sort out the problems on 3.6 or decide to
downgrade to 3.4. In the end, we can keep 3.5 a while longer and wait
for stdenv-upgrades.

Please let me know if I overlooked some use cases for other kernel versions.