Le 11 décembre 2010 11:44:38, Pierre Schmitz a écrit :
On Sun, 12 Dec 2010 01:49:45 +1000, Allan McRae <allan@archlinux.org>
wrote:
Hi,
I am in the progress of updating the toolchain and thought it time to review what our minimum required kernel version is for glibc.
For those that do not know, assuming a newer kernel allows glibc to have less workarounds compiled in. So it may be advantagous to have a more recent version as the minimum required. This comes at the obvious cost of not having support for older kernels so a tradeoff is needed... When we discussed this 18 months ago, it was decided 2.6.18 was appropraite then, but much has changed since.
I am going to suggest that we follow the oldest longterm support kernel. That would now be the 2.6.27.x series, which has been around for over two years.
That might be being overly bold, so feel free to point out how much such an update would break... and suggest an alternative minimum.
Allan
Thanks for bringing this up. This also includes the question for how long we should support updates in general. (I'll open a new thread instead of hijacking this one)
For the minimum kernel requiring the oldest lts one seems sane to me. This should ensure a smooth update even if you use our lts kernel and don't update that often.
3.6.18 was released for years ago, so I don't think a lot of Arch users would be affected.
Greetings,
Pierre
Hi, I like the idea of Pierre to base the minimum version on the lts kernel. The reason is that it is the oldest version for which we are actively providing bugs/security fixes. We could even be audacious and adopt a convention that, at any time, the minimum version of the kernel corresponds to the current lts package. When we will upgrade the lts kernel, we will automatically update the minimum version. I think that udev >= 145-1 requires a minimum kernel version of 2.6.24.5[1], so building glibc for anything older may not make sense. Stéphane [1] http://www.archlinux.org/news/udev-minimum-kernel-version