This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Requiring Linux 3.2 for glibc 2.24



On 11/02/16 15:33, "Mike Frysinger" <vapier@gentoo.org> wrote:

>On 11 Feb 2016 08:54, Dmitry Mishin wrote:
>> > On 02/09/2016 03:54 PM, Florian Weimer wrote:
>> >> On 02/09/2016 03:36 PM, Aurelien Jarno wrote:
>> >> 
>> >>> I am in favor of that. That said when have we tried to do so in
>>Debian
>> >>> stretch/sid (which will be released in 2017), people started to
>> >>>complain
>> >>> loudly that it breaks openvz. We had to revert the change given a
>>lot
>> >>>of
>> >>> VPS providers are using openvz.
>> >>>
>> >>> It seems that openvz is currently not ported on more recent kernels
>> >>>than
>> >>> 2.6.32 and that it will be supported until 2019 for SLES11 and 2020
>>for
>> >>> RHEL7. This unfortunately doesn't encourage openvz to move to newer
>> >>> kernels.
>> >> 
>> >> I've got access to a Virtuozzo container which runs on a commercially
>> >> supported (?) 3.10 kernel variant.
>> > 
>> > It turns out it's lying about the kernel version:
>> > 
>> > <https://bugs.openvz.org/browse/OVZ-5843>
>> >  
>> > Oh dear.
>> 
>> Yep, we have to do this in order still allow OpenVZ users to run desired
>> software
>> inside Containers. Unfortunately, they will to run brand new Linux
>> distributions
>> every time they appear. :)
>> 
>> Seriously, we wouldn't do these hacks if glibc preserve compatibility
>>with
>> old Kernels.
>
>that makes no sense.  glibc already supports 2.6.32 today.  maybe you're
>misattributing the problem to distros or other packages ?  off the top of
>my head, i know udev is pretty aggressive at dropping support for older
>versions of linux.  however, simply lying via uname doesn't actually make
>the code work -- they're requiring newer versions because they expect the
>functionality that's supposed to be in newer versions.  so unless you're
>actually backporting features too (ugh), then your system is broken.
We backport features if they are reported as "some software doesn't work
inside
Containers", but in addition to this, we have to lie about kernel version
- because
Of such sanity checks here and there.

Dmitry.

>-mike


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]