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 <[email protected]>: >> * 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 _______________________________________________ maintainers mailing list [email protected] https://lists.opencsw.org/mailman/listinfo/maintainers .:: This mailing list's archive is public. ::.
