Hi Andreas, I really appreciate your interest as I am try to convince our fellows.
"Andreas K. Huettel" <dilfri...@gentoo.org> writes: > another option would be to (try to) revive glibc-2.5, 2.12, and 2.17 > instead. > Yes I know they are even older, but these are the versions that RHEL > uses, and for which RH still provides support (until 2020 for 2.5, > 2024 for 2.12)... > https://sourceware.org/glibc/wiki/Release#Distribution_Branch_Mapping > That however would require that the RHEL patchsets are public > somehwere. Which I doubt... after all there's an "E" in RHEL... > [...] > ... except that my personal motivation has dropped somewhat when > noticing that the CentOS package applies 552 (!) patches on top of > 2.17. Carrying Redhat patches are not only technical unfeasible, but also out of our best interest. The reasons are the following. glibc-2.5 does not support fortify, thus breaking gentoo version of gcc since verison 4.3 (Bug 289757). The original purpose of prefix-standalone was to introduce newer glibc from gentoo to solve this issue. So shipping glibc-2.5 requires maintaining seperate versions of gcc. glibc has some tolerance for kernel. 2012 glibc-2.16 supports 2004 linux-2.6.8. It buys us 8 years! That's the basis for the magic of prefix-standalone. gcc in turn has some tolerance for glibc. So far glibc-2.16 is still supported by the newest gcc but glibc-2.5 is definitely out of the game. I hear your instinct for RHEL versions for security consideration. But in this use case, the kernels are usually outdated for many years and prone to multiple privilege escalation CVE's. If the administrators of these systems cared about security, these antiques wouldn't have existed in the first place. Therefore, using edge versions of glibc-2.16 (newest glibc to support linux 2.6+) and 2.19 (newest glibc to support linux 2.6.16+) makes more sense. Yours, Benda
signature.asc
Description: PGP signature
