Feature #4070

Update oi-userland versioning scheme

Added by Alexander Pyhalov over 7 years ago. Updated over 4 years ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:


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/ and Timestamp is automatically updated. Now we have BRANCHID set to .

Solaris 11 has the following versioning scheme for BRANCHID:
Branch version. Oracle Solaris packages show the following information in the branch version portion of the version string of a package FMRI:

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

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.

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.

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

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

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$(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
    2. BRANCHID change, regardless of COMPONENT_SUBVERSION
  • 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.

Updated by Aurélien Larcher over 4 years ago

Is it not what you implemented with COMPONENT_REVISION ? Can this be closed ?


Updated by Alexander Pyhalov over 4 years ago

  • Category changed from 35 to OI-Userland
  • Status changed from New to Closed
  • % Done changed from 0 to 50

I think this one can be closed. Andrzej has implemented good scheme. However, we haven't implemented FICTIVE_VERSION. But it has its own advantages, as IPS always shows real package version. So I'm reluctant to doing this.

Also available in: Atom PDF