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