John Plocher wrote: > Didn't we have this very same coexistence conversation the first time > 'round? :-) > > The use case of the user installing gcc 4.3.2 "yesterday", installing > gcc 4.3.3 "today", and then uninstalling gcc 4.3.2 "tomorrow" is going > to be a reasonably common upgrade path; whatever causes the "havoc to > both the files and IPS database" is a bug and must be fixed. Are we > sure this is only a GCC project bug, or is there a related IPS problem > (user provided packages that cause havoc with the IPS system is a > recipe for disaster)?
Potentially, the problem could occur any time packages with overlapping pathnames are installed and one is removed. As I understand it, the pathnames will be removed without IPS realizing they are shared. > > It sounds like there are two related, but independent "projects" here: > > 1) Fix/update the already deployed gcc 4.3.2 packages in the IPS > repo to allow the use > case above, and Correct. > > 2) Release a new set of gcc 4.3.3 packages. Assuming, of course, > that these > packages won't have the upgrade bug that slipped past in > 4.3.2's original release. Correct again. > > Can you point out where the topic of version flexibility, both in the > "co-installed" and "which is the default" areas, is addressed in the > project's packaging design and/or packaging architecture specs? In > particular, I am looking for the architecture (or design pattern...) > that you are following for choosing which compiler version is invoked > via "/usr/bin/gcc" - Is it "last package installed", "first...", some > special per-version "make me the default" package, or something else? In the previous case for 4.3.2, we had proposed adding "plain" links in /usr/bin to the default version of GCC, e.g. /usr/bin/gcc -> gcc-4.3.2. According to the gcc man page, plain gcc should invoke the last version installed. In SVR4 packages, this behavior could be implemented via postinstall and preremove scripts. IPS doesn't support this functionality and the plain links were already taken by GCC 3.4.3. For 2009.06, GCC 3.4.3 is the default and the user can access 4.3.2 by the -V option or the version suffixed commands. verexec seems to be the preferred long term solution. I guess we need to wait for that to do a good job controlling the defaults with multiple versions installed. In my replay to Rainer this morning, I suggested we could use something like gcc4 or gcc43 in the short term for this next release. We are also working with the opensolaris team to see if it makes sense to keep the plain links in /usr/bin at 3.4.3 or possibly move them up to 4.3.3. Thanks, George > > -John > > > On Thu, Oct 22, 2009 at 4:36 PM, George Vasick <George.Vasick at sun.com> > wrote: >> Alan Coopersmith wrote: >>> George Vasick wrote: >>>> We released 4.3.2 in OpenSolaris 2009.06. We have to update 4.3.2 in >>>> order to release 4.3.3 to avoid duplicate pathnames between the packages. >>> The case specified 4.3.2 as a new delivery, not something already >>> provided. >> Sorry about that. Here is a new section 4.10 clarifying the situation: >> >> 4.10. Packaging & Delivery: >> Package Status >> ======= ====== >> SUNWgcc432 Modified >> SUNWgcc433 New >> SUNWgccdoc New >> SUNWgcclibgcc1 New >> SUNWgcclibgfortran3 New >> SUNWgcclibgomp1 New >> SUNWgcclibobjc2 New >> SUNWgcclibssp0 New >> SUNWgcclibstdc6 New >> SUNWgccruntime432 Deleted >> >>> Still, it seems wasteful to ship both, instead of replacing 4.3.2 with >>> 4.3.3 >>> and telling developers who want to stay on 4.3.2 to not upgrade their >>> packages, >>> but that probably depends on IPS/OpenSolaris packaging changes to allow >>> those >>> to be upgraded separately from the WOS build. >> According to my to my IPS contact, installing the new 433 packages over an >> existing 432 install would go through just fine with no warnings or errors. >> Uninstall is another story with all kinds of havoc to both the files and >> IPS database. There were two choices. We could update the 432 packages to >> be empty or modify their contents to allow coexistence. In either case, the >> 432 packages require an update.
