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