Hi Stephan, Thanks for putting together this complete explanation!
My understanding is that folks often want to have multiple versions, so making that use case seamless would be good. I've also seen version info included in the package name for gcc compilers in the Ubuntu repository as well. (There is a non-version gcc package name as well) I'm going to run #2 by the team. We currently have sunstudioexpress and it sounds like you are suggesting we consider having something like this: pkg:/[tools_categories]/[EMAIL PROTECTED] (or something more meaningful, but ordered after "0.") Directory: /opt/SunStudio13/ Summary: Sun Studio Express - C, C++, and Fortran compilers & tools We change the summary when the FCS comes out....and maybe have a sunstudioexpress incorporation (?) for folks who may be looking for that. Thanks again! /kso Stephen Hahn wrote: > * 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 > > > 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 > _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
