[Userland] [OpenIndiana Distribution - Feature #4070] (New) Update oi-userland versioning scheme
devnull at illumos.org
Thu Aug 22 05:17:45 UTC 2013
Issue #4070 has been reported by Alexander Pyhalov.
Feature #4070: Update oi-userland versioning scheme
Author: Alexander Pyhalov
Assignee: OI Userland
h2. 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
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.
h2. 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.
h2. 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
# IPS_COMPONENT_VERSION change, regardless of BRANCHID and COMPONENT_SUBVERSION
# BRANCHID change, regardless of COMPONENT_SUBVERSION
# 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.
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://www.illumos.org/my/account
More information about the Userland-team