Re: [gentoo-dev] rfc: glibc versions prior to 2.19-r1

[William Hubbs]

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.