Oracle Solaris supports multiple architectures, and one common error made with the SVR4 packaging system was the accidental installation of packages for an incorrect architecture. Maintaining separate IPS software repositories for each supported architecture is unappealing to ISVs and error prone for software users. As a result, IPS supports installation of a single package on multiple architectures.
The mechanism that implements this feature is called a variant. A variant enables the properties of the target image to determine which software components are actually installed.
A variant has two parts: its name, and the list of possible values. The variants defined in Oracle Solaris 11 are shown in the following table.
|
Variants appear in the following two places in a package:
A set action names the variant and defines the values that apply to this package.
Any action that can only be installed for a subset of the variant values named in the set action has a tag that specifies the name of the variant and the value on which this action is installed.
For example, a package that delivers the symbolic link /var/ld/64 might include the following definitions:
set name=variant.arch value=sparc value=i386
dir group=bin mode=0755 owner=root path=var/ld
dir group=bin mode=0755 owner=root path=var/ld/amd64 \
variant.arch=i386
dir group=bin mode=0755 owner=root path=var/ld/sparcv9 \
variant.arch=sparc
link path=var/ld/32 target=.
link path=var/ld/64 target=sparcv9 variant.arch=sparc
link path=var/ld/64 target=amd64 variant.arch=i386Note that components that are delivered on both SPARC and x86 receive no variant tag, but components delivered to one architecture or the other receive the appropriate tag. Actions can contain multiple tags for different variant names. For example, a package might include both debug and nondebug binaries for both SPARC and x86.
In Oracle Solaris, kernel components are commonly elided from packages installed in zones, since kernel components serve no useful purpose in a non-global zone. Thus, the kernel components are marked with the opensolaris.zone variant set to global so that they are not installed in non-global zones. This is typically done in the manifest during publication by using a pkgmogrify(1) rule. The packages from the i386 and sparc builds are marked for zones, and then pkgmerge(1) merges packages from the sparc and i386 builds. This is far more reliable and faster than attempting to construct such packages manually.
Package developers should not define new variants other than custom variant.debug.* variants. If a variant is assigned to a component, and that variant has no default value in the image, installation of that package fails. The variant.debug.* portion of the variant namespace is predefined to have a default value of false. Package developers can provide debug versions of components and tag those components with custom variant.debug.* variants. Users can then select that variant if problems arise. Keeping in mind that variants are set per image, select a variant name that is unique at the appropriate resolution for that piece of software.
Variant tags are applied to any actions that differ between architectures during merging, including dependencies and set actions. Packages that are marked as not supporting one of the variant values of the current image are not considered for installation.
The pkgmerge(1) man page provides several examples of merging packages. The pkgmerge command merges across multiple different variants at the same time if needed.