JavaScript is required to for searching.
Skip Navigation Links
Exit Print View
Adding and Updating Oracle Solaris 11 Software Packages     Oracle Solaris 11 Information Library
search filter icon
search icon

Document Information


1.  Introduction to the Image Packaging System

Image Packaging System

Installation Privileges

IPS Concepts

IPS Packages

Fault Management Resource Identifiers

Publishers, Repositories, and Package Archives

Repository Origins and Mirrors

Images and Boot Environments

Package Facets and Variants

2.  IPS Graphical User Interfaces

3.  Getting Information About Software Packages

4.  Installing and Updating Software Packages

5.  Configuring Installed Images

IPS Concepts

This section defines terms and concepts that are used in the remainder of this guide.

IPS Packages

An IPS package is defined by a text file called a manifest. A package manifest describes package actions in a defined format of key/value pairs and possibly a data payload. Package actions include files, directories, links, drivers, dependencies, groups, users, and license information. Package actions represent the installable objects of a package. Actions called “set” actions define package metadata such as classification, summary, and description.

You can search for packages by specifying package actions and action keys. See pkg(5) for descriptions of package actions.

An incorporation is a package that constrains the versions of a specified set of packages. For example, if a package in an installed incorporation is version 1.4.3, then no version less than 1.4.3 or greater than or equal to 1.4.4 can be installed. However, versions that merely extend the dotted sequence, such as, could be installed. Incorporations force the incorporated packages to upgrade synchronously. An incorporated package could be removed, but if the package is installed or updated, the version is constrained.

A group package specifies the set of packages that constitute a feature or tool. Packages specified in a group package do not specify the package version. The group package is a content management tool, not a version management tool.

Fault Management Resource Identifiers

Each package is represented by a Fault Management Resource Identifier (FMRI). The full FMRI for a package consists of the scheme, a publisher, the package name, and a version string in the following format. The scheme, publisher, and version string are optional. When using IPS commands, you can use the smallest portion of the package name that uniquely identifies the package.








If the publisher is specified, then the publisher name must be preceded by pkg:// or //.

Package name


The package namespace is hierarchical and arbitrarily deep. In IPS commands, you can specify the smallest portion of the package name that uniquely identifies the package. If you specify the full package name but omit the publisher, the full package name can be preceded by pkg:/ or / but not by pkg:// or //. If you specify an abbreviated package name, do not use any other characters to the left of the package name.


The package version has four parts:

Component version


For components tightly bound to the operating system, this is usually the value of uname -r for that version of the operating system.

Build version


The build version must follow a comma (,). The build version specifies the version of the operating system on which the contents of the package were built.

Branch version

The branch version must follow a hyphen (-). The branch version provides vendor-specific information.

Time stamp


The time stamp must follow a colon (:). The time stamp is the time the package was published in ISO-8601 basic format: YYYYMMDDTHHMMSSZ.

Publishers, Repositories, and Package Archives

A publisher identifies a person or organization that provides one or more packages. Publishers can distribute their packages using package repositories or package archives. Publishers can be configured into a preferred search order. When a package installation command is given and the package specification does not include the publisher name, the first publisher in the search order is searched for that package. If the package is not found, the second publisher in the search order is searched, and so forth until the package is found or all publishers have been searched.

A repository is a location where packages are published and from where packages are retrieved. The location is specified by a Universal Resource Identifier (URI). A catalog is the list of all the packages in a repository.

A package archive is a file that contains publisher information and one or more packages provided by that publisher.

Repository Origins and Mirrors

An origin is a package repository that contains both package metadata (such as catalogs, manifests, and search indexes) and package content (files). If multiple origins are configured for a given publisher in an image, the IPS client attempts to choose the best origin from which to retrieve package data.

A mirror is a package repository that contains only package content. IPS clients access the origin to obtain a publisher's catalog, even when the clients download package content from a mirror. If a mirror is configured for a publisher, the IPS client prefers the mirror for package content retrieval. If multiple mirrors are configured for a given publisher in an image, the IPS client attempts to choose the best mirror from which to retrieve package content. If all mirrors are unreachable, do not have the required content, or are slower, the IPS client retrieves the content from an origin.

Images and Boot Environments

An image is a location where IPS packages can be installed and where other IPS operations can be performed.

A boot environment (BE) is bootable instance of an image. You can maintain multiple BEs on your system, and each BE can have different software versions installed. When you boot your system, you have the option to boot into any of the BEs on the system. A new BE can be created automatically as a result of package operations. You can also explicitly create a new BE. Whether a new BE is created depends on image policy as described in Boot Environment Policy Image Properties.

Package Facets and Variants

Software can have components that are optional and components that are mutually exclusive. Examples of optional components include locales and documentation. Examples of mutually exclusive components include SPARC or x86 and debug or non-debug binaries. In IPS, optional components are called facets and mutually exclusive components are called variants.

Facets and variants are special properties of the image and cannot be set on individual packages.

Individual actions in package manifests can have facet and variant tags. A single action can have multiple facet and variant tags.

The values of facet and variant tags on an action compared with the values of facets and variants set in the image determine whether that package action can be installed.

To view or modify the values of the facets and variants set on the image, see Controlling Installation of Optional Components.