This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Linux kernel version support policy
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Aaro Koskinen <aaro dot koskinen at iki dot fi>
- Cc: <libc-alpha at sourceware dot org>, Aurelien Jarno <aurel32 at debian dot org>
- Date: Tue, 28 Jan 2014 00:48:39 +0000
- Subject: Re: Linux kernel version support policy
- Authentication-results: sourceware.org; auth=none
- References: <Pine dot LNX dot 4 dot 64 dot 1401272237400 dot 14736 at digraph dot polyomino dot org dot uk> <20140127234925 dot GB589 at drone dot musicnaut dot iki dot fi>
On Tue, 28 Jan 2014, Aaro Koskinen wrote:
> On Mon, Jan 27, 2014 at 11:02:43PM +0000, Joseph S. Myers wrote:
> > 2.6.16 ceased to be maintained in July 2009, according to Wikipedia
> > <https://en.wikipedia.org/wiki/Linux_kernel#Maintenance>. Should we have
> > a policy on how long after a long-term-support Linux kernel version ceases
> > to be maintained we can move the minimum to the next long-term-support
> > version, or such a policy based on distribution releases (or a
> > combination)?
>
> Is it common to upgrade GLIBC but not the kernel? At least I don't think
> any distro does that.
A major reason not just to require a recent 3.x kernel is that people are
developing and testing glibc on systems that may not be running the very
latest distribution versions, and so may have an older kernel; the
question is how much to allow for that.
(I should add something I forgot in my original message: when we increase
the minimum kernel version for use of glibc, the minimum kernel headers
version against which glibc can be built - currently 2.6.19.1 because
that's when headers_install became functional - should also be increased
to match. I hope that's uncontroversial; installing a new set of kernel
headers for glibc builds is straightforward.)
--
Joseph S. Myers
joseph@codesourcery.com