What is the reason for still keeping really old kernel versions with vanilla-sources? That old versions don't receive fixes for a long time, if people want to have long term kernels, they have 3.0 and 3.2. The problem of providing this really old versions is that some people could be tempted to try them to have their old/obsolote external driver still working... even if they will have problems with important core parts like udev. There could be also some security issues that are unfixed in that old kernels. Thanks for the info Reproducible: Always
This is also important to other packages in the tree still supplying things like obsolete v4l1 support even if dropped for a long time in "recent" kernels (I think after 2.6.38)
I think we need to keep at least: -2.6.32.xx -3.0.xx -3.2.xx
No need to CC treecleaners. There is a maintainer for this package
(In reply to comment #0) > What is the reason for still keeping really old kernel versions with > vanilla-sources? That old versions don't receive fixes for a long time, if > people want to have long term kernels, they have 3.0 and 3.2. > > The problem of providing this really old versions is that some people could > be tempted to try them to have their old/obsolote external driver still > working... even if they will have problems with important core parts like > udev. There could be also some security issues that are unfixed in that old > kernels. Linux 2.6.32 works with udev 171, so the only backward compatibility issues would involve Gentoo testing. As for security issues, vanilla sources have a clear disclaimer that they is not supported by Gentoo Security. I agree with Agostino sentiments about retaining certain versions. As for Linux 2.6.16.y, The last release was more than 4 years ago and I see no reason to use it over 2.6.32.y. FreeBSD's linux compatibility layer emulates 2.6.16. My experiments with our current Gentoo Linux stage3 tarballs on Gentoo FreeBSD revealed that they are no longer compatible with Linux 2.6.16. A few binaries such as tar need to be symlinked to busybox to make our userland work on Linux 2.6.16 and that ignores udev, which my FreeBSD experiments did not test at all.
As far as I can be concerned : I like clear and deterministic procedures and trust in volunteering. What about getting inspired by what is worth for packages ? v.g. : 50 days after whatever release is declared EOL by upstream, this release is dropped from portage's tree unless someone volunteers for maintaining it specifically.
(In reply to comment #3) > No need to CC treecleaners. There is a maintainer for this package That was only to remember the case and help dropping old slots if maintainers don't have enough time
(In reply to comment #4) > Linux 2.6.32 works with udev 171, so the only backward compatibility issues > would involve Gentoo testing. As for security issues, vanilla sources have a > clear disclaimer that they is not supported by Gentoo Security. > The problem is that we shouldn't be so far from getting newer udev stabilized (due udisks:0 deprecation in favor of :2 that needs newer udev to properly mount devices), and, for example, udev-195 needs kernel >= 2.6.39
done, old ebuild removed.
Thanks Ago
(In reply to comment #9) > Thanks Ago thanks you for point it out ;)
