* Kuldip Oberoi <[EMAIL PROTECTED]> [2008-04-30 17:18]:
> Stephen Hahn wrote:
> > .... It's not a great idea to name packages with their release
> > characteristics. That's what the version is for.
> >
> > For instance, if sunstudioexpress isn't the name of the final package,
> > then upgrades from
> >
> > pkg:/[EMAIL PROTECTED],5.11-0.86:20080428T164106Z
> >
> > to
> >
> > pkg:/[EMAIL PROTECTED],5.11-1:...
> >
> > are (a) manual by default, and (b) will involve retrieving all of the
> > sunstudio files and deleting all of the sunstudioexpress files.
> >
> > (Not picking on the compilers here, but want to point out authors are
> > on the wrong path if they start naming their packages "foo-beta" and
> > "foo-express", rather than [EMAIL PROTECTED] and then [EMAIL PROTECTED]
> > One for the
> > developer's guide.)
>
> I may not fully understand how this works, but here's a subset of our
> requirements:
>
> 1. Users have the ability to have multiple Sun Studio versions installed
> (Sun Studio 11 [for CBE, for instance], Sun Studio 12 [latest FCS
> release], etc.)
>
> 2. Users are able to get access to the latest public builds via Sun
> Studio Express program (non-FCS) and have them installed next to FCS builds.
>
> Because there is no option to specify destination directory via IPS, we
> thought we'd move to having version specific directories for our FCS
> releases. Because of this, we envisioned that we would have 1
> sunstudioexpress pkg and separate packages for major releases
> (sunstudio11, sunstudio12, ...)
>
> So, in theory, someone can have the following on their system:
>
> /opt/SunStudioExpress/
> /opt/SunStudio12/
> /opt/SunStudio11/
>
>
> My understanding is that if we want to have version specific
> directories, this needs to be associated with a version-specific
> package. However, if a destination directory can be associated with a
> specific _version_ of a package, then we can go with 1 package.
>
> Thoughts? Mis-assumptions I've made, etc.?
(In between one issue and the next, I've almost finished responses to
our first attribute and naming review rounds. But this aspect didn't
present there, so it's good to cover here.) The first point is that
the summary and description attributes are the place for so-called
"marketing" names. The package FMRI is an ID suitable for
programmatic use; it's the API for "a particular piece or pieces of
software. FMRIs need to be of known stability and, eventually, to
change only for very precise reasons.
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.
Cheers
Stephen
--
[EMAIL PROTECTED] http://blogs.sun.com/sch/
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
