osdir.com

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Python-Dev] Drop support for old unsupported FreeBSD and Linux kernels?


On 19 January 2018 at 16:04, Nathaniel Smith <njs at pobox.com> wrote:
> On Thu, Jan 18, 2018 at 12:27 PM, Victor Stinner
> <victor.stinner at gmail.com> wrote:
>> CPython still has compatibility code for Linux 2.6, whereas the
>> support of Linux 2.6.x ended in August 2011, longer than 6 years ago.
>> Should we also drop support for old Linux kernels? If yes, which ones?
>> The Linux kernel has LTS version, the oldest is Linux 3.2 (support
>> will end in May, 2018).
>>
>> Linux kernel support:
>>
>>   https://www.kernel.org/category/releases.html
>
> RHEL 5 uses 2.6.28, and still has "extended life cycle support" until
> 2020, but I guess no-one should be running Python 3.7 on that. CentOS
> 6 and RHEL 6 use 2.6.32, and their EOL is also 2020 (or 2024 for RHEL
> 6 with extended life cycle support). Redhat does ship and support 3.6
> on CentOS/RHEL 6 through their "software collections" product, and
> presumably is planning to do the same for 3.7.
>
> It is a little surprising to see a Redhat employee suggest dropping
> support for RHEL 6. Hopefully you know what you're doing :-)

Red Hat's kernel version numbers describe the *oldest* code in that
kernel, rather than the newest. So if Red Hat customers want to run a
new version of CPython on an older version of RHEL, and the new
version of CPython needs a particular kernel feature, then that turns
into a backport request for that kernel capability (e.g. while there
were multiple drivers for Red Hat backporting the getrandom() syscall
the RHEL 7's 3.10 kernel, CPython was one of them:
https://bugzilla.redhat.com/show_bug.cgi?id=1330000)

So I think it makes sense to base python-dev's Linux kernel support
policy on the community LTS streams for the Linux kernel - if a
commercial Python vendor chooses to go beyond those dates they can,
just as they may go beyond python-dev's nominal support dates for
CPython itself.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia