| 1 |
IMHO, maintaining a sensible set of old glibc versions of the last 5 |
| 2 |
years makes sense, and we should try to support it: |
| 3 |
|
| 4 |
> +1 from me. I cannot think of any scenario where we need to keep such |
| 5 |
> old glibc versions around. |
| 6 |
|
| 7 |
One scenario is to create a cross-compile toolchain with specific old |
| 8 |
versions of gcc/binutils/glibc/linux-headers in mind. |
| 9 |
|
| 10 |
Here, a common problem is that glibc is forward, but not backward |
| 11 |
compatible. Thus, specific old versions of glibc are usually required. |
| 12 |
|
| 13 |
Further, we also maintain a big history of gcc, binutils and |
| 14 |
linux-headers versions. This would become a bit moot when we restrict |
| 15 |
glibc to relatively modern versions. |
| 16 |
|
| 17 |
At least it would limit the usefulness and flexibility of crossdev |
| 18 |
drastically... |
| 19 |
|
| 20 |
|
| 21 |
An alternative approach might be to drop keywords completely from old |
| 22 |
versions that do not get any backports from our side any more. |
| 23 |
With this, those would be still available for crossdev - but without any |
| 24 |
functionality or security guarantee from our side. |
| 25 |
|
| 26 |
As for the issue with functions.sh - I fail to see how this must be |
| 27 |
resolved by dropping old versions... |
| 28 |
|
| 29 |
Best, |
| 30 |
Matthias |
Archives