| 1 |
On Mon, 22 Dec 2014 17:11:01 +0100 Andreas K. Huettel wrote: |
| 2 |
[...] |
| 3 |
> (On a related note, do we really need gcc 2.95.3-r10, 3.3.6-r1, 3.4.6-r2, |
| 4 |
> 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, |
| 5 |
> 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, |
| 6 |
> 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? |
| 7 |
|
| 8 |
Yes, we do. There is a lot of software out there which needs |
| 9 |
specific gcc version. E.g. I have fortran code which depends |
| 10 |
gcc:3.4. Other example are cuda implementations which usually lag |
| 11 |
behind mainstream gcc by one middle version. |
| 12 |
|
| 13 |
And please don't say "just fix it", some of such software is |
| 14 |
binary, some other is too large to be updated regularly. |
| 15 |
|
| 16 |
While one year support is a good policy for a common packages, it |
| 17 |
is in no way an upper limit for support and core packages should be |
| 18 |
considered carefully here. |
| 19 |
|
| 20 |
Best regards, |
| 21 |
Andrew Savchenko |
Archives