rfc: glibc versions prior to 2.19-r1

classic Classic list List threaded Threaded
35 messages Options
12
Reply | Threaded
Open this post in threaded view
|

rfc: glibc versions prior to 2.19-r1

William Hubbs
All,

the following is a comment Mike made about the status of glibc in an
earlier thread on this list:

On Sun, Aug 03, 2014 at 09:16:52AM -0400, Mike Frysinger wrote:

> upstream glibc has dropped support for older Linux kernels.  your choices:
>  - upgrade your kernel
>  - switch to a different C library
>  - stick with glibc-2.19 for a while
>
> be warned though there are no plans atm to backport things to glibc-2.19.  
> this includes security fixes, but more importantly as time moves on, making
> newer gcc versions sanely compile glibc.  we've kept older glibc versions
> around to be nice, and on a part time basis for cross-compiling, but none of
> those are given priority.  i.e. fixes come as people feel like doing them.
>
> certainly once glibc-2.20+ goes stable, there is no expectation let alone
> requirement that packages in the tree be kept working with older glibc
> versions.  the maintenance cost there is unreasonable.
>
> i guess if you're stuck on old crap, now would be a good time to start
> preparing to unstick your crap.  glibc-2.20 will most likely be in ~arch in
> the next 6 months.
> -mike
Since glibc-2.19-r1 is stable everywhere, what I want to know is whether
we can remove versions *prior* to 2.19-r1 at this point.

If we do, that makes it easy to fix bug 478764 [1], because there would
only be three versions of glibc we have to worry about.

thoughts?

William

[1] https://bugs.gentoo.org/show_bug.cgi?id=478764

signature.asc (188 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: rfc: glibc versions prior to 2.19-r1

Markos Chandras-2
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 12/21/2014 03:28 PM, William Hubbs wrote:

> All,
>
> the following is a comment Mike made about the status of glibc in
> an earlier thread on this list:
>
> On Sun, Aug 03, 2014 at 09:16:52AM -0400, Mike Frysinger wrote:
>> upstream glibc has dropped support for older Linux kernels.  your
>> choices: - upgrade your kernel - switch to a different C library
>> - stick with glibc-2.19 for a while
>>
>> be warned though there are no plans atm to backport things to
>> glibc-2.19. this includes security fixes, but more importantly as
>> time moves on, making newer gcc versions sanely compile glibc.
>> we've kept older glibc versions around to be nice, and on a part
>> time basis for cross-compiling, but none of those are given
>> priority.  i.e. fixes come as people feel like doing them.
>>
>> certainly once glibc-2.20+ goes stable, there is no expectation
>> let alone requirement that packages in the tree be kept working
>> with older glibc versions.  the maintenance cost there is
>> unreasonable.
>>
>> i guess if you're stuck on old crap, now would be a good time to
>> start preparing to unstick your crap.  glibc-2.20 will most
>> likely be in ~arch in the next 6 months. -mike
>
> Since glibc-2.19-r1 is stable everywhere, what I want to know is
> whether we can remove versions *prior* to 2.19-r1 at this point.
>
> If we do, that makes it easy to fix bug 478764 [1], because there
> would only be three versions of glibc we have to worry about.
>
> thoughts?
>
> William
>
> [1] https://bugs.gentoo.org/show_bug.cgi?id=478764
>

I suppose it makes sense to drop old glibc ebuilds.

- --
Regards,
Markos Chandras
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQF8BAEBCgBmBQJUlx7ZXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGRDlGMzA4MUI2MzBDODQ4RDBGOEYxMjQx
RjEwRUQ0QjgxREVCRjE5AAoJEB8Q7UuB3r8ZCJ4H/0coofEKcsika34IaHI609gR
Q2ZOhmcgV82wu6zwpIRVQaIDFCfo170c1g6OfffaaVLpu6VrvlN0lOxA0s2fPVuk
pyf3ZjmElVyhncPtfCBIlygfvdabEv5UCEi8dgOe59tz6SyXarvRdKdQOsWy8yRx
38LGDH/vcmlcTbVKXfKuNPZ52hhfTspw7/QDxIqwufDqXaFV/sP+nLRTWKlK293I
twO6biE3m60ggwaEyL5+LT4ZQZTQ2MnfDpBD8Rr1+xPwIj7rvgbJCVul1B1NZq6m
gxYS078K8SeSEroum4wrZKj6OI8oIAic7Apa9wpp+tDXPOMYYn7SxvNtOBVpa/w=
=rlNJ
-----END PGP SIGNATURE-----

Reply | Threaded
Open this post in threaded view
|

Re: rfc: glibc versions prior to 2.19-r1

Sergey Popov
21.12.2014 22:26, Markos Chandras пишет:

> On 12/21/2014 03:28 PM, William Hubbs wrote:
>> All,
>
>> the following is a comment Mike made about the status of glibc in
>> an earlier thread on this list:
>
>> On Sun, Aug 03, 2014 at 09:16:52AM -0400, Mike Frysinger wrote:
>>> upstream glibc has dropped support for older Linux kernels.  your
>>> choices: - upgrade your kernel - switch to a different C library
>>> - stick with glibc-2.19 for a while
>>>
>>> be warned though there are no plans atm to backport things to
>>> glibc-2.19. this includes security fixes, but more importantly as
>>> time moves on, making newer gcc versions sanely compile glibc.
>>> we've kept older glibc versions around to be nice, and on a part
>>> time basis for cross-compiling, but none of those are given
>>> priority.  i.e. fixes come as people feel like doing them.
>>>
>>> certainly once glibc-2.20+ goes stable, there is no expectation
>>> let alone requirement that packages in the tree be kept working
>>> with older glibc versions.  the maintenance cost there is
>>> unreasonable.
>>>
>>> i guess if you're stuck on old crap, now would be a good time to
>>> start preparing to unstick your crap.  glibc-2.20 will most
>>> likely be in ~arch in the next 6 months. -mike
>
>> Since glibc-2.19-r1 is stable everywhere, what I want to know is
>> whether we can remove versions *prior* to 2.19-r1 at this point.
>
>> If we do, that makes it easy to fix bug 478764 [1], because there
>> would only be three versions of glibc we have to worry about.
>
>> thoughts?
>
>> William
>
>> [1] https://bugs.gentoo.org/show_bug.cgi?id=478764
>
>
> I suppose it makes sense to drop old glibc ebuilds.
>
>
+1 from me. They also have various security issues(all that are <2.17
are definitely have them)

--
Best regards, Sergey Popov
Gentoo developer
Gentoo Desktop-effects project lead
Gentoo Proxy maintainers project lead


signature.asc (550 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: rfc: glibc versions prior to 2.19-r1

Lars Wendler
In reply to this post by William Hubbs
On Sun, 21 Dec 2014 09:28:48 -0600 William Hubbs wrote:

>All,
>
>the following is a comment Mike made about the status of glibc in an
>earlier thread on this list:
>
>On Sun, Aug 03, 2014 at 09:16:52AM -0400, Mike Frysinger wrote:
>> upstream glibc has dropped support for older Linux kernels.  your
>> choices:
>>  - upgrade your kernel
>>  - switch to a different C library
>>  - stick with glibc-2.19 for a while
>>
>> be warned though there are no plans atm to backport things to
>> glibc-2.19. this includes security fixes, but more importantly as
>> time moves on, making newer gcc versions sanely compile glibc.
>> we've kept older glibc versions around to be nice, and on a part
>> time basis for cross-compiling, but none of those are given
>> priority.  i.e. fixes come as people feel like doing them.
>>
>> certainly once glibc-2.20+ goes stable, there is no expectation let
>> alone requirement that packages in the tree be kept working with
>> older glibc versions.  the maintenance cost there is unreasonable.
>>
>> i guess if you're stuck on old crap, now would be a good time to
>> start preparing to unstick your crap.  glibc-2.20 will most likely
>> be in ~arch in the next 6 months.
>> -mike
>
>Since glibc-2.19-r1 is stable everywhere, what I want to know is
>whether we can remove versions *prior* to 2.19-r1 at this point.
>
>If we do, that makes it easy to fix bug 478764 [1], because there would
>only be three versions of glibc we have to worry about.
>
>thoughts?
>
>William
>
>[1] https://bugs.gentoo.org/show_bug.cgi?id=478764
+1 from me. I cannot think of any scenario where we need to keep such
old glibc versions around.

Cheers
Lars

--
Lars Wendler
Gentoo package maintainer
GPG: 4DD8 C47C CDFA 5295 E1A6 3FC8 F696 74AB 981C A6FC

attachment0 (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: rfc: glibc versions prior to 2.19-r1

Matthias Maier-3
IMHO, maintaining a sensible set of old glibc versions of the last 5
years makes sense, and we should try to support it:

> +1 from me. I cannot think of any scenario where we need to keep such
> old glibc versions around.

One scenario is to create a cross-compile toolchain with specific old
versions of gcc/binutils/glibc/linux-headers in mind.

Here, a common problem is that glibc is forward, but not backward
compatible. Thus, specific old versions of glibc are usually required.

Further, we also maintain a big history of gcc, binutils and
linux-headers versions. This would become a bit moot when we restrict
glibc to relatively modern versions.

At least it would limit the usefulness and flexibility of crossdev
drastically...


An alternative approach might be to drop keywords completely from old
versions that do not get any backports from our side any more.
With this, those would be still available for crossdev - but without any
functionality or security guarantee from our side.

As for the issue with functions.sh - I fail to see how this must be
resolved by dropping old versions...

Best,
Matthias

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: rfc: glibc versions prior to 2.19-r1

William Hubbs
On Mon, Dec 22, 2014 at 03:18:01PM +0100, Matthias Maier wrote:
> IMHO, maintaining a sensible set of old glibc versions of the last 5
> years makes sense, and we should try to support it:

We have a general policy in the distro that says we only have to worry
about one year. Besides that, linux-2.6.32, which is the oldest kernel
glibc-2.20 will support was released in 2009, so I think it is
reasonable to drop the old glibc versions.

>
> > +1 from me. I cannot think of any scenario where we need to keep such
> > old glibc versions around.
>
> One scenario is to create a cross-compile toolchain with specific old
> versions of gcc/binutils/glibc/linux-headers in mind.
>
> Here, a common problem is that glibc is forward, but not backward
> compatible. Thus, specific old versions of glibc are usually required.
>
> Further, we also maintain a big history of gcc, binutils and
> linux-headers versions. This would become a bit moot when we restrict
> glibc to relatively modern versions.
As has already been stated, older than glibc-2.20 will not be considered
supported once 2.20 hits stable, and 2.20 works with >=linux-2.6.32,
which was released in 2009.

Furthermore, I still think we need to look at how far back we are going
with gcc/binutils/linux-headers.

>
> At least it would limit the usefulness and flexibility of crossdev
> drastically...
>
>
> An alternative approach might be to drop keywords completely from old
> versions that do not get any backports from our side any more.
> With this, those would be still available for crossdev - but without any
> functionality or security guarantee from our side.

An even better way to do this would be for someone to make an overlay
somewhere if they want this old stuff. I'm not saying that people
shouldn't be able to use it, but we shouldn't carry it in the main
portage tree. After all, we are not a software archival service.

William

signature.asc (188 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: rfc: glibc versions prior to 2.19-r1

Rich Freeman
On Mon, Dec 22, 2014 at 10:04 AM, William Hubbs <[hidden email]> wrote:
> On Mon, Dec 22, 2014 at 03:18:01PM +0100, Matthias Maier wrote:
>> IMHO, maintaining a sensible set of old glibc versions of the last 5
>> years makes sense, and we should try to support it:
>
> We have a general policy in the distro that says we only have to worry
> about one year. Besides that, linux-2.6.32, which is the oldest kernel
> glibc-2.20 will support was released in 2009, so I think it is
> reasonable to drop the old glibc versions.
>

I think a general policy like this makes sense.  Nothing prevents a
maintainer from keeping around stuff longer, but that should be up to
them (and issues in old versions shouldn't be the responsibility of
others to clean up if they are blockers - just move forward and let
things break after a warning or treeclean if the problem is really
serious).

Manpower is limited in Gentoo in general, and there is little point in
pouring a lot of it into one particular package unless you pour just
as much effort into other related packages.  By having a guideline of
one year it gives everybody something to aim for - we keep around
year-old kernels that work with year-old gcc and glibc and year-old
sysvinit implementations, and so on.  It also lets our users have a
sense up-front of what to expect - they /might/ happen to get a bit
more out of the odd package, but we're not RHEL.

If somebody wants to run a "Gentoo Ancient" overlay or such, more power to them!

--
Rich

Reply | Threaded
Open this post in threaded view
|

Re: rfc: glibc versions prior to 2.19-r1

Anthony G. Basile
On 12/22/14 10:39, Rich Freeman wrote:

> On Mon, Dec 22, 2014 at 10:04 AM, William Hubbs <[hidden email]> wrote:
>> On Mon, Dec 22, 2014 at 03:18:01PM +0100, Matthias Maier wrote:
>>> IMHO, maintaining a sensible set of old glibc versions of the last 5
>>> years makes sense, and we should try to support it:
>> We have a general policy in the distro that says we only have to worry
>> about one year. Besides that, linux-2.6.32, which is the oldest kernel
>> glibc-2.20 will support was released in 2009, so I think it is
>> reasonable to drop the old glibc versions.
>>
> I think a general policy like this makes sense.  Nothing prevents a
> maintainer from keeping around stuff longer, but that should be up to
> them (and issues in old versions shouldn't be the responsibility of
> others to clean up if they are blockers - just move forward and let
> things break after a warning or treeclean if the problem is really
> serious).

Please let's not "tidy up" gentoo.  That "old" stuff is useful even if
its not useful to those who don't see a use for it.  Let the maintainers
decide if they want to put effort into keeping it around.


--
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : [hidden email]
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA


Reply | Threaded
Open this post in threaded view
|

Re: rfc: glibc versions prior to 2.19-r1

Andreas K. Huettel
Am Montag, 22. Dezember 2014, 16:52:22 schrieb Anthony G. Basile:
>
> Please let's not "tidy up" gentoo.  That "old" stuff is useful even if
> its not useful to those who don't see a use for it.  Let the maintainers
> decide if they want to put effort into keeping it around.

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?

(On a related note, do we really need gcc 2.95.3-r10, 3.3.6-r1, 3.4.6-r2,
4.0.4, 4.1.2, 4.2.4-r1, 4.3.6-r1, 4.4.7, 4.5.1-r1, 4.5.2, 4.5.3-r2, 4.5.4,
4.6.0, 4.6.1-r1, 4.6.2, 4.6.3, 4.6.4, 4.7.0, 4.7.1, 4.7.2-r1, 4.7.3-r1, 4.7.4,
4.8.0, 4.8.1-r1, 4.8.2, 4.8.3, 4.9.0, 4.9.1, and (deep breath) 4.9.2?

I mean, it's not as if these were the exact same packages as when originally
stabilized, in an archiving sense, since in the meantime random eclass
settings were flipped around.)

+1 for an "archive overlay"

--

Andreas K. Huettel
Gentoo Linux developer
[hidden email]
http://www.akhuettel.de/


signature.asc (970 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: rfc: glibc versions prior to 2.19-r1

Andrew Savchenko
On Mon, 22 Dec 2014 17:11:01 +0100 Andreas K. Huettel wrote:
[...]
> (On a related note, do we really need gcc 2.95.3-r10, 3.3.6-r1, 3.4.6-r2,
> 4.0.4, 4.1.2, 4.2.4-r1, 4.3.6-r1, 4.4.7, 4.5.1-r1, 4.5.2, 4.5.3-r2, 4.5.4,
> 4.6.0, 4.6.1-r1, 4.6.2, 4.6.3, 4.6.4, 4.7.0, 4.7.1, 4.7.2-r1, 4.7.3-r1, 4.7.4,
> 4.8.0, 4.8.1-r1, 4.8.2, 4.8.3, 4.9.0, 4.9.1, and (deep breath) 4.9.2?

Yes, we do. There is a lot of software out there which needs
specific gcc version. E.g. I have fortran code which depends
gcc:3.4. Other example are cuda implementations which usually lag
behind mainstream gcc by one middle version.

And please don't say "just fix it", some of such software is
binary, some other is too large to be updated regularly.

While one year support is a good policy for a common packages, it
is in no way an upper limit for support and core packages should be
considered carefully here.

Best regards,
Andrew Savchenko

attachment0 (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: rfc: glibc versions prior to 2.19-r1

Matthias Maier-3
In reply to this post by Andreas K. Huettel

> +1 for an "archive overlay"

This sounds like a reasonable compromise.

For the toolchain.eclass problem you mentioned. We could just version
the eclass as needed, something like toolchain-crossdev-vX.eclass. With
this development on the main repository is independent and we would
still have old versions around for crossdev.

Same goes for gcc, and binutils.

Best,
Matthias

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: rfc: glibc versions prior to 2.19-r1

Anthony G. Basile
In reply to this post by Andreas K. Huettel
On 12/22/14 11:11, Andreas K. Huettel wrote:

> Am Montag, 22. Dezember 2014, 16:52:22 schrieb Anthony G. Basile:
>> Please let's not "tidy up" gentoo.  That "old" stuff is useful even if
>> its not useful to those who don't see a use for it.  Let the maintainers
>> decide if they want to put effort into keeping it around.
> 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?

>
> (On a related note, do we really need gcc 2.95.3-r10, 3.3.6-r1, 3.4.6-r2,
> 4.0.4, 4.1.2, 4.2.4-r1, 4.3.6-r1, 4.4.7, 4.5.1-r1, 4.5.2, 4.5.3-r2, 4.5.4,
> 4.6.0, 4.6.1-r1, 4.6.2, 4.6.3, 4.6.4, 4.7.0, 4.7.1, 4.7.2-r1, 4.7.3-r1, 4.7.4,
> 4.8.0, 4.8.1-r1, 4.8.2, 4.8.3, 4.9.0, 4.9.1, and (deep breath) 4.9.2?

Between 4.8.3 and 4.8.4 there were 80 bug fixes with a yet unknown
number of regressions.  Most people that hit these kinds of problems
revert to the previous working versions.  Add to that the quantum leaps
between 4.X and 4.(X+1) with no backwards compat in abis. Plus the fact
that some sensitive software usually aimed a special chips need specific
versions and the answer is ... yes.

What happened here (in part) is the way we're doing multilib is
percolating through gentoo and hitting things it doesn't mesh with
well.  That's fine we have to glue things together correctly. Throwing
stuff away when it doesn't mesh is not fine when its something good.

>
> I mean, it's not as if these were the exact same packages as when originally
> stabilized, in an archiving sense, since in the meantime random eclass
> settings were flipped around.)
>
> +1 for an "archive overlay"
>


--
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : [hidden email]
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA


Reply | Threaded
Open this post in threaded view
|

Re: rfc: glibc versions prior to 2.19-r1

Anthony G. Basile
In reply to this post by Andrew Savchenko
On 12/22/14 11:20, Andrew Savchenko wrote:

> On Mon, 22 Dec 2014 17:11:01 +0100 Andreas K. Huettel wrote:
> [...]
>> (On a related note, do we really need gcc 2.95.3-r10, 3.3.6-r1, 3.4.6-r2,
>> 4.0.4, 4.1.2, 4.2.4-r1, 4.3.6-r1, 4.4.7, 4.5.1-r1, 4.5.2, 4.5.3-r2, 4.5.4,
>> 4.6.0, 4.6.1-r1, 4.6.2, 4.6.3, 4.6.4, 4.7.0, 4.7.1, 4.7.2-r1, 4.7.3-r1, 4.7.4,
>> 4.8.0, 4.8.1-r1, 4.8.2, 4.8.3, 4.9.0, 4.9.1, and (deep breath) 4.9.2?
> Yes, we do. There is a lot of software out there which needs
> specific gcc version. E.g. I have fortran code which depends
> gcc:3.4. Other example are cuda implementations which usually lag
> behind mainstream gcc by one middle version.

Its not as corner as people think it is.  I wasn't even thinking of cuda.

>
> And please don't say "just fix it", some of such software is
> binary, some other is too large to be updated regularly.
>
> While one year support is a good policy for a common packages, it
> is in no way an upper limit for support and core packages should be
> considered carefully here.

Thank you.

>
> Best regards,
> Andrew Savchenko


--
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : [hidden email]
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA


Reply | Threaded
Open this post in threaded view
|

Re: rfc: glibc versions prior to 2.19-r1

Rich Freeman
In reply to this post by Anthony G. Basile
On Mon, Dec 22, 2014 at 10:52 AM, Anthony G. Basile <[hidden email]> wrote:

> On 12/22/14 10:39, Rich Freeman wrote:
>>
>> On Mon, Dec 22, 2014 at 10:04 AM, William Hubbs <[hidden email]>
>> wrote:
>>>
>>> On Mon, Dec 22, 2014 at 03:18:01PM +0100, Matthias Maier wrote:
>>>>
>>>> IMHO, maintaining a sensible set of old glibc versions of the last 5
>>>> years makes sense, and we should try to support it:
>>>
>>> We have a general policy in the distro that says we only have to worry
>>> about one year. Besides that, linux-2.6.32, which is the oldest kernel
>>> glibc-2.20 will support was released in 2009, so I think it is
>>> reasonable to drop the old glibc versions.
>>>
>> I think a general policy like this makes sense.  Nothing prevents a
>> maintainer from keeping around stuff longer, but that should be up to
>> them (and issues in old versions shouldn't be the responsibility of
>> others to clean up if they are blockers - just move forward and let
>> things break after a warning or treeclean if the problem is really
>> serious).
>
>
> Please let's not "tidy up" gentoo.  That "old" stuff is useful even if its
> not useful to those who don't see a use for it.  Let the maintainers decide
> if they want to put effort into keeping it around.
>

Wasn't that what I just said?  Maintainers decide what they want to
put effort into maintaining.  The only bit I added beyond what you
said is that if they DON'T maintain the old versions others don't have
to do it for them.  (ie, bugs against them don't count as blockers
towards other changes in the tree)  Treecleaning is only appropriate
if things are horribly broken, which is the usual policy.

--
Rich

Reply | Threaded
Open this post in threaded view
|

Re: rfc: glibc versions prior to 2.19-r1

Rich Freeman
In reply to this post by Andrew Savchenko
On Mon, Dec 22, 2014 at 11:20 AM, Andrew Savchenko <[hidden email]> wrote:

> On Mon, 22 Dec 2014 17:11:01 +0100 Andreas K. Huettel wrote:
> [...]
>> (On a related note, do we really need gcc 2.95.3-r10, 3.3.6-r1, 3.4.6-r2,
>> 4.0.4, 4.1.2, 4.2.4-r1, 4.3.6-r1, 4.4.7, 4.5.1-r1, 4.5.2, 4.5.3-r2, 4.5.4,
>> 4.6.0, 4.6.1-r1, 4.6.2, 4.6.3, 4.6.4, 4.7.0, 4.7.1, 4.7.2-r1, 4.7.3-r1, 4.7.4,
>> 4.8.0, 4.8.1-r1, 4.8.2, 4.8.3, 4.9.0, 4.9.1, and (deep breath) 4.9.2?
>
> Yes, we do. There is a lot of software out there which needs
> specific gcc version. E.g. I have fortran code which depends
> gcc:3.4. Other example are cuda implementations which usually lag
> behind mainstream gcc by one middle version.
>
> And please don't say "just fix it", some of such software is
> binary, some other is too large to be updated regularly.
>

You don't have to fix that software.  You just have to sign up to
co-maintain gcc so that you can take care of all those old versions
you want to keep and ensure that they don't break when there are
changes to other packages.  I just proposed that it should be up to
the maintainer, which can be you.

I could care less if gcc has 300 versions in the tree - I'd say 300 is
better than 5.  I just don't expect that other package maintainers
deal with bugs like "can't stabilize foo-6 because it will make
systems running a 4-year-old version of gcc unbootable."  If an
upcoming change makes gcc-2.95 systems unbootable they can just log a
bug and a news item assuming somebody notices it before it gets
committed (maybe giving the gcc maintainer a week to fix it before
plowing ahead), and if nobody notices it before it goes stable no big
deal.  If you're running such oddball configurations on Gentoo that is
what we're all about, but you should be thoroughly testing changes
before deploying them in production because certainly nobody else is
going to do it for you...

--
Rich

Reply | Threaded
Open this post in threaded view
|

Re: rfc: glibc versions prior to 2.19-r1

Andreas K. Huettel
In reply to this post by Andrew Savchenko
Am Montag, 22. Dezember 2014, 17:20:31 schrieb Andrew Savchenko:

> On Mon, 22 Dec 2014 17:11:01 +0100 Andreas K. Huettel wrote:
> [...]
>
> > (On a related note, do we really need gcc 2.95.3-r10, 3.3.6-r1, 3.4.6-r2,
> > 4.0.4, 4.1.2, 4.2.4-r1, 4.3.6-r1, 4.4.7, 4.5.1-r1, 4.5.2, 4.5.3-r2,
> > 4.5.4, 4.6.0, 4.6.1-r1, 4.6.2, 4.6.3, 4.6.4, 4.7.0, 4.7.1, 4.7.2-r1,
> > 4.7.3-r1, 4.7.4, 4.8.0, 4.8.1-r1, 4.8.2, 4.8.3, 4.9.0, 4.9.1, and (deep
> > breath) 4.9.2?
>
> Yes, we do. There is a lot of software out there which needs
> specific gcc version. E.g. I have fortran code which depends
> gcc:3.4. Other example are cuda implementations which usually lag
> behind mainstream gcc by one middle version.
Which gives us 3.4, 4.6, 4.7, 4.8, 4.9 at most.

> And please don't say "just fix it",

I'm not saying "just fix it", I'm saying "... and of course you will happily
join toolchain team and/or maintain the single gcc version that you need, at
your own pace".

> 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'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.

--

Andreas K. Huettel
Gentoo Linux developer
[hidden email]
http://www.akhuettel.de/


signature.asc (970 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: rfc: glibc versions prior to 2.19-r1

Andreas K. Huettel
In reply to this post by Anthony G. Basile
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.

> > (On a related note, do we really need gcc 2.95.3-r10, 3.3.6-r1, 3.4.6-r2,
> > 4.0.4, 4.1.2, 4.2.4-r1, 4.3.6-r1, 4.4.7, 4.5.1-r1, 4.5.2, 4.5.3-r2,
> > 4.5.4, 4.6.0, 4.6.1-r1, 4.6.2, 4.6.3, 4.6.4, 4.7.0, 4.7.1, 4.7.2-r1,
> > 4.7.3-r1, 4.7.4, 4.8.0, 4.8.1-r1, 4.8.2, 4.8.3, 4.9.0, 4.9.1, and (deep
> > breath) 4.9.2?
>
> Between 4.8.3 and 4.8.4 there were 80 bug fixes with a yet unknown
> number of regressions.  Most people that hit these kinds of problems
> revert to the previous working versions.  

OK, so then let's keep all 4.7.x, 4.8.x, 4.9.x, the latest stable 4.5 and 4.6,
and maybe 3.4.

> Add to that the quantum leaps
> between 4.X and 4.(X+1) with no backwards compat in abis. Plus the fact
> that some sensitive software usually aimed a special chips need specific
> versions and the answer is ... yes.

One of the many moments when I really wish we had gentoostats up and running.

Is it possible to emerge @system with, say, e.g. gcc-4.0 or 4.1?

From the discussions about hardened 3.x is still interesting. But how much can
you still do with it, does anyone try regularly?

Is anyone even testing 2.95 anymore?

> What happened here (in part) is the way we're doing multilib is
> percolating through gentoo and hitting things it doesn't mesh with
> well.  That's fine we have to glue things together correctly. Throwing
> stuff away when it doesn't mesh is not fine when its something good.

Please explain the specific connection of this problem with multilib.
(Shouldn't you usually use the same gcc version for your whole system as far
as you can?)

--

Andreas K. Huettel
Gentoo Linux developer
[hidden email]
http://www.akhuettel.de/


signature.asc (970 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: rfc: glibc versions prior to 2.19-r1

Rich Freeman
In reply to this post by Andreas K. Huettel
On Mon, Dec 22, 2014 at 4:22 PM, Andreas K. Huettel
<[hidden email]> wrote:
> Am Montag, 22. Dezember 2014, 17:20:31 schrieb Andrew Savchenko:
>
>> And please don't say "just fix it",
>
> I'm not saying "just fix it", I'm saying "... and of course you will happily
> join toolchain team and/or maintain the single gcc version that you need, at
> your own pace".
>

This really is the basic principle that tends to govern most of these
things.  This isn't about getting rid of stuff that people want to
take care of.  This is about not forcing devs to take care of software
that they have no desire to take care of.  Nobody is preventing
anybody from maintaining old versions of gcc/glibc/linux/etc.  I'm
sure everybody would be happy to work with anybody who is active and
doing such things.  The problem comes in when people want to hold up
stabilization of other packages or changes to eclasses/profiles/etc on
the grounds that some ancient version of glibc that nobody is actually
bothering to maintain will be broken by the change.

If you don't have a policy like this, then people just give up on
doing new things with Gentoo, and then all that you have left are
people who want the old things but can't be bothered to keep them
working.  The goal here is to keep the effort required to take Gentoo
in a new direction low.  That is how we end up with things like
Prefix, multilib (in its various forms), multiple init
implementations, and so on.

As long as somebody makes sure that the old versions of glibc will
continue to boot when their dependencies are satisfied, then nobody is
going to force anybody to remove them.  The onus is just on those who
want to keep those packages to ensure that they are maintained.

--
Rich

Reply | Threaded
Open this post in threaded view
|

Re: rfc: glibc versions prior to 2.19-r1

Andrew Savchenko
In reply to this post by Andreas K. Huettel
On Mon, 22 Dec 2014 22:22:41 +0100 Andreas K. Huettel wrote:

> Am Montag, 22. Dezember 2014, 17:20:31 schrieb Andrew Savchenko:
> > On Mon, 22 Dec 2014 17:11:01 +0100 Andreas K. Huettel wrote:
> > [...]
> >
> > > (On a related note, do we really need gcc 2.95.3-r10, 3.3.6-r1, 3.4.6-r2,
> > > 4.0.4, 4.1.2, 4.2.4-r1, 4.3.6-r1, 4.4.7, 4.5.1-r1, 4.5.2, 4.5.3-r2,
> > > 4.5.4, 4.6.0, 4.6.1-r1, 4.6.2, 4.6.3, 4.6.4, 4.7.0, 4.7.1, 4.7.2-r1,
> > > 4.7.3-r1, 4.7.4, 4.8.0, 4.8.1-r1, 4.8.2, 4.8.3, 4.9.0, 4.9.1, and (deep
> > > breath) 4.9.2?
> >
> > Yes, we do. There is a lot of software out there which needs
> > specific gcc version. E.g. I have fortran code which depends
> > gcc:3.4. Other example are cuda implementations which usually lag
> > behind mainstream gcc by one middle version.
>
> Which gives us 3.4, 4.6, 4.7, 4.8, 4.9 at most.
That was just two examples from my experience. Other users may
have different demands. That's why I'm not sure it is safe to
remove 2.95. Also people may need older versions for testing (e.g.
to check for possible regressions).

As far as I understand right now older gcc versions are not a large
maintenance hassle, so to be on a safe side we should keep the
latest version on each branch. That is exactly what is done right
now: prior to (4.5) we have only latest ebuild per branch.

> > And please don't say "just fix it",
>
> I'm not saying "just fix it", I'm saying "... and of course you will happily
> join toolchain team and/or maintain the single gcc version that you need, at
> your own pace".

Frankly I had thoughts about joining toolchain, but probably I'm
too green as a Gentoo dev to do this right now.

> > 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'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.
I can't justify for you each gcc version in the list, but I already
described use cases I encountered. The main point is that most
users don't read this list and it is highly likely that people need
another gcc versions for similar reasons but for a different
software.

As far as I understand from this discussion, a main issue is that
proposed changes in toolchain.eclass will broke old ebuilds.
Solution looks very simple to me: just use toolchain-v2.eclass for
new stuff.

Best regards,
Andrew Savchenko

attachment0 (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: rfc: glibc versions prior to 2.19-r1

William Hubbs
In reply to this post by Andreas K. Huettel
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 (188 bytes) Download Attachment
12