On Mon, Dec 22, 2014 at 03:18:01PM +0100, Matthias Maier wrote: > IMHO, maintaining a sensible set of old glibc versions of the last 5 > years makes sense, and we should try to support it:
We have a general policy in the distro that says we only have to worry about one year. Besides that, linux-2.6.32, which is the oldest kernel glibc-2.20 will support was released in 2009, so I think it is reasonable to drop the old glibc versions. > > > +1 from me. I cannot think of any scenario where we need to keep such > > old glibc versions around. > > One scenario is to create a cross-compile toolchain with specific old > versions of gcc/binutils/glibc/linux-headers in mind. > > Here, a common problem is that glibc is forward, but not backward > compatible. Thus, specific old versions of glibc are usually required. > > Further, we also maintain a big history of gcc, binutils and > linux-headers versions. This would become a bit moot when we restrict > glibc to relatively modern versions. As has already been stated, older than glibc-2.20 will not be considered supported once 2.20 hits stable, and 2.20 works with >=linux-2.6.32, which was released in 2009. Furthermore, I still think we need to look at how far back we are going with gcc/binutils/linux-headers. > > At least it would limit the usefulness and flexibility of crossdev > drastically... > > > An alternative approach might be to drop keywords completely from old > versions that do not get any backports from our side any more. > With this, those would be still available for crossdev - but without any > functionality or security guarantee from our side. An even better way to do this would be for someone to make an overlay somewhere if they want this old stuff. I'm not saying that people shouldn't be able to use it, but we shouldn't carry it in the main portage tree. After all, we are not a software archival service. William
signature.asc
Description: Digital signature
