Software Distributor Administration Guide (March 2009)

swlist -l product -a software_spec
A common practice is to install a second version of the product. When installing this
software, a new location must be selected. In the case of the product Foo, the new
location might be /opt/foo.v2. After specifying the new location (i.e., by adding
l=/opt/foo.v2 after the product tag in the GUI or CLI), swinstall will replace
the product directory portion of all files with the new product location.
NOTE: The allow_multiple_versions option must be set to true for swinstall
to install multiple versions of the software. The new version will not be configured by
swinstall if there is another version configured.
After a second version has been installed, each version can be identified either by the
location (Foo,l=/opt/foo and Foo,l=/opt/foo.v2), by the revision (Foo,r=1.0
and Foo,r=2.0), or both. You can list the locations and revisions of all versions with:
swlist -l fileset -a location -a revision
Additionally, you can list a fully qualified software spec containing both the location and
revision as well as the other version distinguishing attributes (vendor and architecture)
with:
swlist -l fileset -a software_spec
After the new version is installed successfully for all products or on all hosts, the old
version can be unconfigured, and the new version configured as the active version by
using swconfig -u with the old version and swconfig with the new version.
NOTE: By default, only one version of the software is allowed to be configured at a
time.
The second version can not be configured until the first one is unconfigured. As was
discussed in “Installation With Separate Configuration” (page 179), installing a second
version automatically excludes configuring the new version.
You must manually unconfigure the old version, then configure the new version. If
the software supports multiple configured versions (in addition to multiple installed
versions) the swconfig.allow_multiple_versions option can be set to true.
In case of any problems, the old version can be restored as the active version by
unconfiguring the new version and reconfiguring the old (i.e., by swconfig -u with
the new version and swconfig with the old version).
In order to support multiple versions, the software must be structured so that all files
are below the product directory, and the configure scripts need to be written with
multiple version support in mind. In a simple example, the configure script could add
a symbolic link from /usr/bin/foo to $SW_LOCATION/bin/foo, and the unconfigure
script could remove that link. In this example, configuring and unconfiguring each
version of this software is easily done.
180 Reliability and Performance