Gentoo Archives: gentoo-dev

From: Rich Freeman <rich0@g.o>
To: gentoo-dev <gentoo-dev@l.g.o>
Subject: Re: [gentoo-dev] rfc: glibc versions prior to 2.19-r1
Date: Mon, 22 Dec 2014 21:45:45
Message-Id: CAGfcS_k6enov39Em=fc6FEYWqLBz98shriay9sKDj9CDbO35UA@mail.gmail.com
In Reply to: Re: [gentoo-dev] rfc: glibc versions prior to 2.19-r1 by "Andreas K. Huettel"
1 On Mon, Dec 22, 2014 at 4:22 PM, Andreas K. Huettel
2 <dilfridge@g.o> wrote:
3 > Am Montag, 22. Dezember 2014, 17:20:31 schrieb Andrew Savchenko:
4 >
5 >> And please don't say "just fix it",
6 >
7 > I'm not saying "just fix it", I'm saying "... and of course you will happily
8 > join toolchain team and/or maintain the single gcc version that you need, at
9 > your own pace".
10 >
11
12 This really is the basic principle that tends to govern most of these
13 things. This isn't about getting rid of stuff that people want to
14 take care of. This is about not forcing devs to take care of software
15 that they have no desire to take care of. Nobody is preventing
16 anybody from maintaining old versions of gcc/glibc/linux/etc. I'm
17 sure everybody would be happy to work with anybody who is active and
18 doing such things. The problem comes in when people want to hold up
19 stabilization of other packages or changes to eclasses/profiles/etc on
20 the grounds that some ancient version of glibc that nobody is actually
21 bothering to maintain will be broken by the change.
22
23 If you don't have a policy like this, then people just give up on
24 doing new things with Gentoo, and then all that you have left are
25 people who want the old things but can't be bothered to keep them
26 working. The goal here is to keep the effort required to take Gentoo
27 in a new direction low. That is how we end up with things like
28 Prefix, multilib (in its various forms), multiple init
29 implementations, and so on.
30
31 As long as somebody makes sure that the old versions of glibc will
32 continue to boot when their dependencies are satisfied, then nobody is
33 going to force anybody to remove them. The onus is just on those who
34 want to keep those packages to ensure that they are maintained.
35
36 --
37 Rich