On Mon, Dec 22, 2014 at 11:20 AM, Andrew Savchenko <[email protected]> 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
