On Tue, Dec 23, 2014 at 5:36 AM, Anthony G. Basile <bluen...@gentoo.org> wrote: > On 12/22/14 16:37, Andreas K. Huettel wrote: >> >> Am Montag, 22. Dezember 2014, 18:24:32 schrieb Anthony G. Basile: >> >>>> Well the side effect of this is that arcane and unmaintainable bandworms >>>> like toolchain.eclass are generated, with dozens of case distinctions >>>> for packages that *nearly* noone needs. Yes it's fine to keep old things >>>> for a few people, does it merit slowing everyone else down though? >>>> >>>> Do we really need glibc 2.9_p20081201-r3, 2.10.1-r1, 2.11.3, 2.12.1-r3, >>>> 2.12.2, 2.13-r2, 2.14, 2.14.1-r2, 2.14.1-r3, 2.15-r1, 2.15-r2, 2.15-r3, >>>> 2.16.0, 2.17, 2.18-r1, 2.19, 2.19-r1, and 2.20? >>> >>> I can't fully speak to this as I'm not familiar. But are you? >> >> No, I'm not. Which is why I am asking. I'm happy to learn. > > > Shall I google that for you? j/k Here are the change logs -> > http://www.gnu.org/software/libc/ There are always some big ticket items > like I remember when -lrt stuff was moved into glibc or further back when > resolver stuff was moved out. Each of these changes usually means breakage > usually in terms of what breakout libraries you need and what linker flags > you need. But I can't pretend to have watched it closely like I'm sure Mike > does. I've watched musl and uclibc and just hit up against the glibc > changes as they mysteriously rain down from Drepper.
Sorry, what would he be Googling? He asked why we needed all of the various old versions, not why new versions keep coming out. Also, Drepper hasn't been involved with glibc development in two and a half years.
