JavaScript is required to for searching.
Skip Navigation Links
Exit Print View
Packaging and Delivering Software With the Image Packaging System in Oracle Solaris 11.1     Oracle Solaris 11.1 Information Library
search filter icon
search icon

Document Information


1.  IPS Design Goals, Concepts, and Terminology

2.  Packaging Software With IPS

3.  Installing, Removing, and Updating Software Packages

4.  Specifying Package Dependencies

5.  Allowing Variations

Mutually Exclusive Software Components

Optional Software Components

6.  Modifying Package Manifests Programmatically

7.  Automating System Change as Part of Package Installation

8.  Advanced Topics For Package Updating

9.  Signing IPS Packages

10.  Handling Non-Global Zones

11.  Modifying Published Packages

A.  Classifying Packages

B.  How IPS Is Used To Package the Oracle Solaris OS

Mutually Exclusive Software Components

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.

Variant Name
Possible Values
sparc, i386
global, nonglobal
true, false

Variants appear in the following two places in a package:

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 \
dir group=bin mode=0755 owner=root path=var/ld/sparcv9 \
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=i386

Note 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 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 cannot define new variants. However, developers can provide debug versions of components, tagged with a variant.debug.* variant, and users can select that variant if problems arise. The variant.debug.* portion of the variant namespace is predefined to have a default value of false. Remember that variants are set per image, so be sure to select a suitable 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.