From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 734EF1382C5 for ; Mon, 26 Feb 2018 17:33:29 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id DBB4EE0A0B; Mon, 26 Feb 2018 17:33:23 +0000 (UTC) Received: from mail-ua0-x22d.google.com (mail-ua0-x22d.google.com [IPv6:2607:f8b0:400c:c08::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 7DA1BE0A00 for ; Mon, 26 Feb 2018 17:33:23 +0000 (UTC) Received: by mail-ua0-x22d.google.com with SMTP id n48so11106565uae.13 for ; Mon, 26 Feb 2018 09:33:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=scriptkitty-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to; bh=UrN0OAlrYa6rtqo4X3kuP9vAdn8if3PdrCs1DwgOyJY=; b=NT4SiIUynbHIXSimlAwArQj06IXh4nFJJoptVcac64w8zEAIyIt3UX958p6cPBNIJM nBFUvHTT5El3TNxe/AJFTWcBFqUiBm8NxK10GRPRZcaCEWAEfYlzNJ7AfgdWafuSX3r+ 1uBSAXOtAx4TsLKhW+ultVLMyqZHLyH+ZgVB4u3iFox+Sfb+NNvFu6CblHaMrOFURHt5 PlJTVMfkXF+vCAmkTu1nQUNvyOKhzYI0Gb9cwhOFBGlNf07KdAHmaP7mIgoaN/TCeruJ gaDng6C5VBEL2pksIFl3eJDWFIqPaZx2zfOLyD2czK5ASqXeZPM8GKiV4YjRmDHCanSH Hdkw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to; bh=UrN0OAlrYa6rtqo4X3kuP9vAdn8if3PdrCs1DwgOyJY=; b=cgLSQGe5G2nA93i9D0SdGcINC4EU8SavfnT4LSaK3PwgGIe33xebMU5TdMSEBa1u5n 6bzvvjs3yKJGN03rt8NMYY7mdY88uSz98OJkvQBdW1/G67ziuKiVdRrkY9Vzvgr4RyYO TEWB3Ks1bq1fF9rFEZCkpJQhsMbPpOFK+lQa+GEc9dpdFqILkltU55j6owmohyv3pady igk4Dl3m+tWE22c7qkU6+yzwz6vSjWXnssgh5U2Mc/DJWG9KrrBZPMVPUbNs/ffsGQno pec1sNKtNxcfA3eZBIpz63jC6chAT5pAUkGb36Z/diZjyGqEdiq9Q/wBYwV+d2E/SKAy lerA== X-Gm-Message-State: APf1xPCITf4e0pdiePyVCTSxbUD/YuEiSr4rCv+n5H8dTdT7aCVGq0Ow DmzkIKQ6nJHS2El4W/U2r7dmJXLK9X6xEmbPCw978w== X-Google-Smtp-Source: AG47ELt1pwclXyVPwpHTUe5fxkgLAQZg+b/VcbNaXPLmK+pmMuQGk4TpBG8U1vX/E7BtyP90GeVkYLiWR4bycNKQb/8= X-Received: by 10.176.32.16 with SMTP id v16mr8827115uak.20.1519666402231; Mon, 26 Feb 2018 09:33:22 -0800 (PST) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Sender: antarus@scriptkitty.com Received: by 10.176.85.93 with HTTP; Mon, 26 Feb 2018 09:33:21 -0800 (PST) X-Originating-IP: [2620:0:1003:512:7847:8c74:a887:ffc1] In-Reply-To: <20180226172220.GA14345@whubbs1.gaikai.biz> References: <87o9kdsid0.fsf@gentoo.org> <1519549826.4602.0.camel@gentoo.org> <20180226172220.GA14345@whubbs1.gaikai.biz> From: Alec Warner Date: Mon, 26 Feb 2018 12:33:21 -0500 X-Google-Sender-Auth: ZNuq8DwZtwoXsqYiEfGm6rogeBI Message-ID: Subject: Re: [gentoo-dev] glibc 2.16/19 for Gentoo Prefix on antique kernels To: Gentoo Dev Content-Type: multipart/alternative; boundary="f4030437d45c154bda056620e861" X-Archives-Salt: ffc7c3e4-83c2-4a4d-a93a-c2aca66d3f74 X-Archives-Hash: 79b613ad33bb5cd5e47551d7e0551d7a --f4030437d45c154bda056620e861 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Feb 26, 2018 at 12:22 PM, William Hubbs wrote= : > On Sun, Feb 25, 2018 at 10:10:26AM +0100, Micha=C5=82 G=C3=B3rny wrote: > > W dniu nie, 25.02.2018 o godzinie 15=E2=88=B617 +0900, u=C5=BCytkownik = Benda Xu > > napisa=C5=82: > > > Hi all, > > > > > > Yes, it's 2018. But there are still RHEL 4 and 5 systems running > > > antique kernels such as 2.6.8 and 2.6.18. In my experience, many of > > > them are data acquisition hubs or computing clusters. No administrat= or > > > cares about security as long as they "work". > > > > > > Under the form "Prefix", Gentoo is set out to rescue users trapped in > > > these abandoned wastelands of antiques. After years of work, we have > > > achieved that goal, except one minor thing: glibc periodically drop > > > support for old linux kernels, the lastest glibc supporting linux 2.6= .8 > > > is 2.16 and for linux-2.6.18 it is glibc-2.19. > > > > > > With the recent reunion of the Toolchain Project, old glibc versions > are > > > masked and removed, accelerating the adoption of new versions. This > > > opens a new oppotunity for the Prefix: people stops caring about > > > unsupported glibc versions, the Prefix Project can take them over > > > without worrying about breaking other peoples' machines. > > > > > > Now, profiles/default/linux/amd64/17.0/no-multilib/prefix/ > kernel-2.6.16+ > > > unmasks > > /lib/gentoo/functions.sh transition. prefix/kernel-2.6+ with > glibc-2.16 > > > is also planned. In addition, glibc have to be patched to get python= 3 > > > built[1-3], which is urgent once portage drops python2[4]. > > > > > > > > > So I would like to hear what you guys think if I: > > > > > > - keep glibc-2.19 and glibc-2.16 in tree and unmasking them in the > > > selected Prefix profiles; > > > > > > - maintain those selected outdated glibc versions on the > > > infrastructure of the Toolchain Project[5]; > > > > > > - (optional) add an exception to the toolchain support policy[6]. > > > > > > How about moving them to an overlay? > > I am with mgorny on this, this sort of specialized support does not > belong in the main tree. So I actually originally thought this as well and settled on some logic that is: The problem we are trying to solve is supporting very old distros. This has two impacts on the tree: a) Very old versions of some packages stay in the tree because they are needed to support these old platforms. b) Very old versions of some packages will need to drop keywords for 'rolling' platforms. E.g. I'd expect glibc-really-old to be keyworded only for 'prefix' but not for 'x86' or 'amd64'. This is because the latter two are not well tested[1] A and B are both mostly about control and maintenance of the tree itself (these do not necessarily reflect the quality or stability of prefix as a platform.) The separate problem is: Given some prefix users are running prefix on these old platforms, how do we detect when support for them breaks (as it did for py3, and will again in the future when something else critical breaks.) I'm curious to hear more about this process, but I think its orthogonal to in-tree or in-overlay support; other than the overlay gives you more control over when to release / withdraw various package versions (more control than just keywords do in the main tree.) Note that Gentoo itself purports to offer only 1 year of support for the main tree; so just based on that axiom alone I think trying to support 10+ year old platforms goes against what the main-tree is targeting. -A > The kernel versions you are talking about aren't even supported by the > upstream kernel folks any more -- the oldest lts version is 3.2.99. > > Thanks, > > William > > --f4030437d45c154bda056620e861 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On M= on, Feb 26, 2018 at 12:22 PM, William Hubbs <williamh@gentoo.org&g= t; wrote:
On Sun, Feb 25, 2018 at 10:10:26AM +0100, Micha=C5=82 G=C3= =B3rny wrote:
> W dniu nie, 25.02.2018 o godzinie 15=E2=88=B617=E2=80=89+0900, u=C5=BC= ytkownik Benda Xu
> napisa=C5=82:
> > Hi all,
> >
> > Yes, it's 2018.=C2=A0 But there are still RHEL 4 and 5 system= s running
> > antique kernels such as 2.6.8 and 2.6.18.=C2=A0 In my experience,= many of
> > them are data acquisition hubs or computing clusters.=C2=A0 No ad= ministrator
> > cares about security as long as they "work".
> >
> > Under the form "Prefix", Gentoo is set out to rescue us= ers trapped in
> > these abandoned wastelands of antiques.=C2=A0 After years of work= , we have
> > achieved that goal, except one minor thing: glibc periodically dr= op
> > support for old linux kernels, the lastest glibc supporting linux= 2.6.8
> > is 2.16 and for linux-2.6.18 it is glibc-2.19.
> >
> > With the recent reunion of the Toolchain Project, old glibc versi= ons are
> > masked and removed, accelerating the adoption of new versions.=C2= =A0 This
> > opens a new oppotunity for the Prefix: people stops caring about<= br> > > unsupported glibc versions, the Prefix Project can take them over=
> > without worrying about breaking other peoples' machines.
> >
> > Now, profiles/default/linux/amd64/17.0/no-multilib/prefix/kernel-2.6.16+
> > unmasks <glibc-2.18. Some pathes needs to be backported, like = the
> > /lib/gentoo/functions.sh transition.=C2=A0 prefix/kernel-2.6+ wit= h glibc-2.16
> > is also planned.=C2=A0 In addition, glibc have to be patched to g= et python3
> > built[1-3], which is urgent once portage drops python2[4].
> >
> >
> > So I would like to hear what you guys think if I:
> >
> >=C2=A0 =C2=A0- keep glibc-2.19 and glibc-2.16 in tree and unmaskin= g them in the
> >=C2=A0 =C2=A0 =C2=A0selected Prefix profiles;
> >
> >=C2=A0 =C2=A0- maintain those selected outdated glibc versions on = the
> >=C2=A0 =C2=A0 =C2=A0infrastructure of the Toolchain Project[5]; > >
> >=C2=A0 =C2=A0- (optional) add an exception to the toolchain suppor= t policy[6].
>
>
> How about moving them to an overlay?

I am with mgorny on this, this sort of specialized support does= not
belong in the main tree.

So I actually orig= inally thought this as well and settled on some logic that is:
The problem we are trying to solve is supporting very old dist= ros. This has two impacts on the tree:
=C2=A0 a) Very old version= s of some packages stay in the tree because they are needed to support thes= e old platforms.
=C2=A0 b) Very old versions of some packages wil= l need to drop keywords for 'rolling' platforms. E.g. I'd expec= t glibc-really-old to be keyworded only for 'prefix' but not for &#= 39;x86' or 'amd64'. This is because the latter two are not well= tested[1]

A and B are both mostly about control a= nd maintenance of the tree itself (these do not necessarily reflect the qua= lity or stability of prefix as a platform.)

The se= parate problem is:
Given some prefix users are running prefix on = these old platforms, how do we detect when support for them breaks (as it d= id for py3, and will again in the future when something else critical break= s.) I'm curious to hear more about this process, but I think its orthog= onal to in-tree or in-overlay support; other than the overlay gives you mor= e control over when to release / withdraw various package versions (more co= ntrol than just keywords do in the main tree.)
=C2=A0
N= ote that Gentoo itself purports to offer only 1 year of support for the mai= n tree; so just based on that axiom alone I think trying to support 10+ yea= r old platforms goes against what the main-tree is targeting.
-A


The kernel versions you are talking about aren't even supported by the<= br> upstream kernel folks any more -- the oldest lts version is 3.2.99.

Thanks,

William


--f4030437d45c154bda056620e861--