[csw-maintainers] Reasons for gcc to have a separate prefix

[Dagobert Michelsen]

Hi,

Am 27.08.2011 um 13:27 schrieb Maciej Bliziński:

> Hi Peter,
> 
> Thanks a lot for the write-up.  You're helping us avoid the old mistakes.
> 
> 2011/8/26 Peter FELECAN <pfelecan at opencsw.org>:
>> * History:
>> - gcc2:
>>  - until the end of 2004 it was maintained by Phil Brown and Markus Gyger
>>  - I took it up and provided the packages
>>  - at that time, some projects' preferred compiler set was that
>>        branch, e.g., MPlayer
> 
> That would be the biggest problem with deprecating old compilers.  I
> think it might occur again when gcc does a major update in the future,
> so we need to have a plan.
> 
>> - gcc3
>>  - same story as for gcc2
>>  - the last supported version for this branch, 3.4.6, is available
>> - gcc4
>>  - I maintained this branch since March 2005, the last version that I
>>    delivered was 4.0.2
>>  - after 2006, Mike Waters was the maintainer for this branch
>> * Prefix:
>>  the separate prefix was the rule from the beginning and it was
>>  enforced by the previous release manager; I proposed at the time an
>>  alternatives system but to no avail, BTW, this is why I implemented a
>>  specific alternative system for Emacs.
>> * Proposition for the future:
>>  Support only one branch, 4, but use alternatives for supporting
>>  different releases and make provision for a 5th branch; I think that
>>  I can release a branch 3 package using alternatives after it's
>>  implemented in the 4th.
> 
> The gcc build system supports adding a binary prefix, so we could set
> it to something like "gcc4" and have gcc4gcc, gcc4g++, etc. That would
> also start matching the package names.
> 
> However, alternatives are not a viable solution for the buildfarm. We
> all work on the same hosts and we need to make it possible to build
> with gccN and gcc(N+1) at the same time.  You can't have buildfarm
> admins flip symlink every time a maintainer wants to switch between
> e.g. gcc-3 and gcc-4.
> 
> How about this plan:
> 
> - we support one current/blessed version of gcc, which lives in /opt/csw
> - when there's a need to have an old version of gcc available, we
> recompile the old version into a separate prefix, as a legacy mode
> 
> The algorithm goes like this:
> 
> T = 1
> gccN: prefix=/opt/csw
> 
> T = 2
> gccN: prefix=/opt/csw/gccN (recompile)
> gcc(N+1): prefix=/opt/csw
> 
> T = 3
> gccN: prefix=/opt/csw/gccN
> gcc(N+1): prefix=/opt/csw/gcc(N+1)
> gcc(N+2): prefix=/opt/csw
> 
> etc.
> 
> The annoying part of this plan is that you have to recompile the old
> version of gcc to make it available, you can't just let the packages
> be.  When you replace gccN with gcc(N+1), you have to make the extra
> effort of moving gccN into own prefix.  I consider it a reasonable
> trade off.

What about the "jdk" technique to always package with prefix and link CSWgcc in
/opt/csw/bin to the latest or as alternative? This would sacve repckaging on
update.


Best regards

  -- Dago