On Wed, Apr 30, 2008 at 1:55 PM, Stephen Hahn <[EMAIL PROTECTED]> wrote: > So, the choices here can be split into two categories: > > 1. Installation of multiple versions. Tom points out that user > images are being introduced expressly for this case--I would > emphasize that for complex stacks of software, installer programs > should in fact offer user images as the preferred way to deliver > related sets of software. Shawn mentions that it should be easy > to have multiple versions installed, without going through the > user image step, which is also true for some classes of software. > > Everybody's right: this choice is a design decision for the > package author. > > If you expect that having > > /opt/SunStudio11 > /opt/SunStudio12 > > is the common case, then you should have > > pkg:/[tools_categories]/[EMAIL PROTECTED] > pkg:/[tools_categories]/[EMAIL PROTECTED] > > so that both packages can be installed, and we can use a group > package like the current "ss-dev" to manage the preferred > configuration. > > If you instead expect that most sites would like a preferred > configuration with a single version, and that complex development > sites should use user images, then you would just have > > pkg:/[tools_categories]/[EMAIL PROTECTED] > pkg:/[tools_categories]/[EMAIL PROTECTED] > > with a clear upgrade path being defined automatically. > > 2. Handling of pre-release versions. Pre-release versions are > different. Here the goal is to keep the pre-release aligned with > the general release as much as possible; that means identifying > the FMRI and the destination paths early. Why? Well, it makes > upgrade for your beta customers automatic, it minimizes > operational costs of that upgrade, and it lets potentially > dependent software components make adjustments during the > pre-release phase (which is usually one of the goals for such a > phase...). What that means is that package version numbering and > product names may need to depart to retain efficiencies and > seamless operation. > > (Sites that want to continue to run a pre-release version--because > organizational needs forced a standardization on a beta product > (as often happens)-- would need to use a user image to do so.) > > So I would expect the current sunstudioexpress package to be renamed > to sunstudio13, with a version number much lower than 13.0. A trick > we've been using is the "0." prefix on the hypothetical final version > number--that should keep the version ordering correct for most cases. > (If anyone's really worried, prefix with "0.0.".) The package summary > could be "Sun Studio Express - C, C++, and Fortran compilers", or > whatever is deemed appropriate.
Well said Stephen; that matches my expectations exactly. As an application developer I can see myself using Studio12 or 13, while as a contributor to ON, I stick with Studio 11. Since the ON consolidation is likely to always be behind in compiler versions, I would hope that the /opt/'SunStudio11, /opt/SunStudio12 approach is used. Cheers, -- Shawn Walker "To err is human -- and to blame it on a computer is even more so." - Robert Orben _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
