On Tue, Dec 23, 2014 at 09:10:32AM +0100, Matthias Maier wrote: > I'm a bit surprised about this discussion as Mike, who currently > maintains the toolchain, has never implied that suddenly older versions > of glibc are unusable. Or that we need a big cleanup. > > He simply stated two facts (that have been true for a long time) > > - for a current kernel a current toolchain is necessary and vice versa. > > - we support older versions of glibc (gcc/etc.) mainly for crossdev > (and some other special purposes) on a best effort basis without any > usability or security guarantees. > > The latter implies that you should not actively use them in your regular > Gentoo setup, not that they must be removed from the tree. I cc'd Mike on my original message in this thread specifically because I hoped he would see it and tell me if I was wrong to start discussing a cleanup, because I read part of his message as implying that a cleanup might be coming.
Specifically, he also said that if you were stuck on old stuff you should start unsticking your stuff. > just the simple fact that crossdev without the ability to select > specific versions of glibc is only half as useful. And please, do not > underestimate the usefulness of our crossdev script in this regard! I'm not saying anything about breaking the crossdev script by making it unable to select specific versions of glibc. > Because you're arguing that no example was presented: > E.g. I've an embedded armv7a-hardfloat board which ships with glibc > 2.16 (This is a concrete example and not a vague "some users might need > it".). I want to have a cross compile environment for it to compile some > specific software (not a complete userland). I do not want to replace > the userland/ship a custom sysroot/use an LD_LIBRARY_PATH hack, so I'm > basically forced to compile with a glibc of at most 2.16 (otherwise you > get symbol lookup errors.) Ok, this is something to consider then. 2.16 is not all that old, so keeping it around for a while longer isn't a big deal. > To ease the maintenance burden there are multiple possibilities to > tackle it without removing old glibc versions altogether: > > - We could debundle newer glibc versions from toolchain.eclass/eblits I don't see toolchain.eclass being inherited in the glibc ebuilds; it is just eblits. Honestly I wouldn't have a problem with seeing them die in all versions of the ebuilds if we can make that happen. > - We could migrate older versions in a dedicated overlay with some > sort of versioned toolchain.eclass/eblits. (same for the other > canonical packages). It looks like there already is a toolchain overlay that might have this, check git.overlays.gentoo.org. > > Further, if the fact that specific versions are unmaintained (and do not > get any security backports) it is also possible to just drop keywords. (qa hat on for this statement only) as a qa member, my opinion on this is, if something has a serious security issue which the maintainer knows is not going to be fixed, it doesn't belong in the main tree.
signature.asc
Description: Digital signature
