| 1 |
All, |
| 2 |
|
| 3 |
this discussion got side-tracked into gcc, which was not my intent; |
| 4 |
let's go back to my specific question about glibc. |
| 5 |
|
| 6 |
On Mon, Dec 22, 2014 at 10:22:41PM +0100, Andreas K. Huettel wrote: |
| 7 |
> > some of such software is |
| 8 |
> > binary, some other is too large to be updated regularly. |
| 9 |
> |
| 10 |
> Please give REASONS why things should remain maintained. So far (except for |
| 11 |
> the gcc-3/hardened explanations, and for gcc-3 doing more fortran than |
| 12 |
> gcc-4(??)) this is mostly mumbo-jumbo about "someone might need it", |
| 13 |
> proprietary binary blobs (should we even care? if yes, why?) and similar. |
| 14 |
|
| 15 |
I vote that we shouldn't care about proprietary binary blobs. |
| 16 |
|
| 17 |
> I'm VERY happy to hear arguments. Especially if they come with good practical |
| 18 |
> and detailed examples that we all can understand. I guess we're all curious to |
| 19 |
> learn about more Gentoo use cases. |
| 20 |
|
| 21 |
With regard to keeping old glibc versions, as far as I |
| 22 |
can tell, there are no dependencies in the tree that require a specific |
| 23 |
version of glibc. |
| 24 |
|
| 25 |
Also, the oldest kernel I see is far newer than 2.6.32, which is the |
| 26 |
oldest kernel being maintained upstream. |
| 27 |
|
| 28 |
Because of that, i see no reason to keep the older versions of glibc |
| 29 |
around. This would also give us a chance to clean up the ebuilds without |
| 30 |
causing massive breakage. the eblits need to die. |
| 31 |
|
| 32 |
Crossdev was mentioned in discussions on irc, but again it wasn't clear |
| 33 |
to me why specific versions of glibc are needed. I don't know of any |
| 34 |
hard dependencies in the portage tree like that. |
| 35 |
|
| 36 |
If someone can point to a concrete example of why we should keep |
| 37 |
the older versions of glibc, I would like to hear it. |
| 38 |
|
| 39 |
|
| 40 |
Thanks, |
| 41 |
|
| 42 |
William |
Archives