On Mon, Feb 26, 2018 at 12:22 PM, William Hubbs <willi...@gentoo.org> wrote:
> On Sun, Feb 25, 2018 at 10:10:26AM +0100, Michał Górny wrote: > > W dniu nie, 25.02.2018 o godzinie 15∶17 +0900, użytkownik Benda Xu > > napisał: > > > 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 administrator > > > 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 <glibc-2.18. Some pathes needs to be backported, like the > > > /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 python3 > > > 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 > >
