Am Sonntag, 25. Februar 2018, 07:17:47 CET schrieb Benda Xu: > 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.
Well, in principle the idea is OK. We already/still keep some old glibc, gcc, and binutils versions for that reason. However, I have a few conditions. * Only masked. Only prefix keywords. If you really must unmask them in a specific prefix profile, you must provide big fat warnings about the resulting security risks. (I dont know how things went in prehistoric times, but recently there have been a LOT of glibc-related CVEs. Many fixes can be backported, but definitely not all of them.) * No toolchain-glibc.eclass or eblits or similar abominations. Standard QA rules apply. * Try to stick to a minimum of required features (and a minimum of required versions). We want to strongly avoid adding conditionals to other packages. [#] * Please use our gentoo glibc repo to keep track of branches and patchsets. Happy to show you the details sometime soon. [#] If not for such "old version" considerations, we could soon move the libtirpc headers to the place where the glibc headers used to live. That could save us a ...load of patching and bugfixing. By keeping flexibility and compatibility, that is unfortunately not possible. -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, perl, libreoffice, comrel)
signature.asc
Description: This is a digitally signed message part.
