thoughts welcomed on this ...
thanks,
-ethan
Problem/Background
----------------------------------
With pkg-based installs, we've run into some incompatibility
problems as we've released later development builds that
aren't compatible with older installers, as seen in a few posts
from early triers of AI. This will be an on-going issue as we
develop new features into the installer, and we currently don't
handle this as nicely or intelligently as we could.
Proposed Solutions
-------------------------------
[0*] Download the installer from pkg branch requested to be
installed. This solution involves extreme refactoring of the
installer architecture to dummy-down the install media, and
to store the real guts of the installer elsewhere. This solution
is not being considered for this proposal, but isn't precluded
from any future rework.
[1] A simple, conservative, solution to this problem would be to
restrict that install media only be able to support pkg-based
installs for packages of the same build as was used to build the
install media.
Since in most cases, a random development build N install
image could potentially, and usually likely, be able to install
pkg-based bits of build N+1 for example, the enforcement could
be lightweight --perhaps just a warning message on the console
and/or log. E.g.
WARNING: The build of the packages being installed, build X,
is not supported by this installer which was built using build Y.
Install will proceed, however the installed system is not
guaranteed to be installed properly.
[2] Embed variability into the process such that the install image
is able to determine if the pkg branch being requested to be
installed is supported by it. For example, use an install image
built from build N to do a pkg-based install of build N+2. The
installer knows its able to support this scenario and allows the
install to complete with no warnings. This provides more support
flexibility to the user, but requires a little more upfront work from
development.
Initial Impl. Details for [2]
------------------------------------------
The install image built with build X is obviously built before future
builds, build X+1, build X+2, ... etc, so it is impossible to directly
embed into the installer what builds it can support. So this
compatibility knowledge must be placed with the packaged install
bits themselves. So the proposal here is to create a new package,
SUNWinstall_compat, which for each build will define which
builds of the installer is able to support installing that build. The
new package would contain a simple text file with
MIN_INSTALL_COMPAT_BUILD=
MAX_INSTALL_COMPAT_BUILD=
2.1 Installer changes
The installer will be enhanced to download the requested build's
SUNWinstall_compat package first, then check that the build it
was built with falls within the MIN and MAX value.
if (requested build has no SUNWinstall_compat package)
WARNING: no SUNWinstall_compat pkg found. Install will
proceed, but ...
else if (install image build is out of range of MIN and MAX)
WARNING: this install image is not supported to install
build X. Install will proceed, but ....
2.2 SUNWinstall_compat package
The new SUNWinstall_compat package will deliver a text file
with the MIN and MAX build numbers defining which builds of
the install image are supported to install that build of the
packages. This package is not installed on the installed machine.
MIN_INSTALL_COMPAT_BUILD=[integer: 0,infinity]
MIX_INSTALL_COMPAT_BUILD=[integer: 0,infinity]
The MIN_INSTALL_COMPAT_BUILD value needs to be updated
only when known Flag Days occur for the Installer installing
pkg-based bits. For example, if in build 115, we need to make
changes in ICT to support pkg-based installing of build 115, then
we update the MIN_INSTALL_COMPAT_BUILD value in build 115
to be 115. Any previous build installer will now emit a WARNING
when they pkg-base install bld 115. If we happen to forget to
update this file for build 115, its easily back-publishable since its
just a text file.
The MAX_INSTALL_COMPAT_BUILD value should always be left
as infinity for new builds. This value is useful only to be
backpublished when we know of changes to the installer that
prevent it from being able to install some older build.
For example, if in build 120, we make changes to the installer
such that it can no longer pkg-base install build 111 on back,
then we backpublish the SUNWinstall_compat package for builds
111 on back to have a MAX value of 119 (or back until we hit some
build that already has a value for MAX)
Issues
----------
[2] assumes one shared base of installer tools wrt pkg-based
installs. i.e. a LiveCD pkg-based installer and the AI pkg-based
installer wouldn't have different installer compatibility boundaries.
Otherwise separate sets of MIN and MAX values would have to
be defined for each pkg-based installer.
