OpenIndiana Distribution

Current state¶

Currently, we have the following versioning scheme in oi-userland. Package version (VERSION,Build Release-Branch:Timestamp)
usually is determined as ($IPS_COMPONENT_VERSION),$(BUILD_VERSION), where $BUILD_VERSION is determined as $(PKG_SOLARIS_VERSION)-$(BRANCHID) in make-rules/ips-buildinfo.mk and Timestamp is automatically updated. Now we have BRANCHID set to 0.151.1.8.1 .

Solaris 11 has the following versioning scheme for BRANCHID: http://docs.oracle.com/cd/E26502_01/html/E21383/glyvm.html#scrolltoc

0.175.1.0.0.2.1
Branch version. Oracle Solaris packages show the following information in the branch version portion of the version string of a package FMRI:

0.175
Major release number. The major or marketing development release build number. In this example, 0.175 indicates Oracle Solaris 11.

1
Update release number. The update release number for this Oracle Solaris release. 
The update value is 0 for the first customer shipment of an Oracle Solaris release, 
1 for the first update of that release, 2 for the second update of that release, and so forth.
 In this example, 1 indicates Oracle Solaris 11.1.

0
SRU number. The Support Repository Update (SRU) number for this update release.
SRUs include only bug fixes; they do not include new features. 
The Oracle Support Repository is available only to systems under a support contract.

0
Reserved. This field is not currently used for Oracle Solaris packages.

2
SRU build number. The build number of the SRU, or the respin number for the major release.

1
Nightly build number. The build number for the individual nightly builds.

The problems¶

I see two problems with current versioning scheme.

• Firstly, we don't have a way to automatically trigger package clean and rebuild if Makefile is not changed during package update (for example, when maintainer change patch to a packge). This currently is worked around by manual gmake clean on server or insignificant Makefile modification (for example, adding some spaces to Makefile triggers clean-publish events).
• Second (and more serious) trouble is that we don't have a way of automatically downgrading package versions. And in /hipster when we update packages we sometimes can't predict what other packages and in what way this update affects. Recent examples - zlib update breaking Firefox, some vagueness with sqlite update.

Proposed solution¶

I think that following can work.

• Adding to oi-userland build system additional COMPONENT_SUBVERSION variable (0 by default) which indicates local change of the package and must be changed with every local package modification. It is resetted to 0 when upstream component version updates. BUILD_VERSION is set to $(PKG_SOALRIS_VERSION)-$(BRANCHID).$(COMPONENT_SUBVERSION). So that new package versions will look like 0.151.1.8.1.$(COMPONENT_SUBVERSION). We should require that maintainer changes COMPONENT_SUBVERSION on every change in the package. In this way the first problem is solved - every time the package is changed, Makefile is affected and clean rebuild is triggered. Also we have a way for end user to determine if package was just rebuilt or significantly changed. Also note, that in this package versioning scheme update can be triggered by
1. IPS_COMPONENT_VERSION change, regardless of BRANCHID and COMPONENT_SUBVERSION
2. BRANCHID change, regardless of COMPONENT_SUBVERSION
3. COMPONENT_SUBVERSION change

• Adding to oi-userland build system constant FICTIVE_VERSION. For all packages which should be downgraded set IPS_COMPONENT_VERSION to FICTIVE_VERSION and change only COMPONENT_SUBVERSION incrementally. We can reset COMPONENT_SUBVERSION to 0 when CONSTANT_BUILD_VERSION is incremented. Real package version should be set as HUMAN_VERSION and determine pkg.human-version IPS property. FICTIVE_VERSION should be an arbitrary high number (100, 511, 1000, as you like) so that it is more than any sane real package version. So, when we set IPS_COMPONENT_VERSION to FICTIVE_VERSION we can trigger IPS package update even when we really downgrade the package.