IMHO, maintaining a sensible set of old glibc versions of the last 5 years makes sense, and we should try to support it:
> +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. 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. As for the issue with functions.sh - I fail to see how this must be resolved by dropping old versions... Best, Matthias
signature.asc
Description: PGP signature
