JavaScript is required to for searching.
Skip Navigation Links
Exit Print View
Oracle Solaris 11 Express Image Packaging System Guide     Oracle Solaris 11 Express 11/10
search filter icon
search icon

Document Information


1.  Introduction to the Image Packaging System

Image Packaging System

IPS Concepts

IPS Packages

Fault Management Resource Identifiers

Publishers and Repositories

Repository Origins and Mirrors

Images and Boot Environments

Package Variants and Facets

2.  IPS Graphical User Interfaces

3.  Working With Packages

4.  Creating and Managing Images

A.  IPS Command Reference


IPS Concepts

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

IPS Packages

IPS manages software in units of packages. An IPS package is a collection of directories, files, links, drivers, dependencies, groups, users, and license information in a defined format. This collection represents the installable objects of a package. Packages have attributes such as package name and description.

You can use commands to view information about a package, or you can view the manifest for a package.

IPS supports both IPS packages and SVR4 packages.

There is no standard on-disk format for an IPS package. IPS does not have an equivalent for .rpm, SVR4 package, or .nbm files.

Fault Management Resource Identifiers

Each IPS package is represented by a Fault Management Resource Identifier (FMRI).

The FMRI includes descriptive information about the package, such as the package name, version information, and date, as shown in the following example:


Publishers and Repositories

Multiple repositories can contain packages with the same name. Publishers can be configured into a preferred search order in each image. When a package is selected for installation, the preferred publisher is searched first for that package, then the next most preferred publisher is searched until the package is found or all publishers have been searched.

A repository URI is not required to contain the name of the publisher. For example, the solaris publisher publishes to repositories hosted at

Repository Origins and Mirrors

A repository has an origin and zero or more mirrors.

Mirrors provide a subset of the data that origins provide. Mirrors can be used only for downloading package files. Package metadata is downloaded from the origin. IPS clients access the origin to obtain a publisher's catalog, even when the clients download package content from a mirror.

Images and Boot Environments

A new BE is automatically created when you perform one of the following operations:

Often a new BE is created when you execute the pkg update command to update all packages that have updates available.

If a new BE is created, the system performs the following steps:

  1. Creates a clone of the current BE that is a bootable image.

    The clone BE includes everything hierarchically under the main root dataset of the original BE. Shared file systems are not under the root dataset and are not cloned. Instead, the BE accesses the original shared file systems.

  2. Updates the packages in the clone BE, but does not update any packages in the current BE.

    If zones are configured in the current BE, these existing zones are configured in the new BE. However, packages are not installed or updated in these zones. You must manually update each zone in the new BE.

  3. Sets the new BE as the default boot choice the next time the system is booted. The current BE remains as an alternate boot choice.

Several IPS commands provide the following options to support BE creation. Check the applicable man page.

--be-name BEname

Assign BEname to the newly created BE. This option is ignored if a new BE is not created.


Do not create a new BE, even if a new BE is required by the components to be installed. If this option is specified and a new BE is required, the operation is not performed.


Create a new BE, even if a new BE is not required.

If a new BE is required but not enough space is available to create a new BE, you might be able to delete existing unneeded BEs. For more information about BEs, see the Managing Boot Environments With Oracle Solaris 11 Express guide.

Package Variants and Facets

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. Both variants and facets appear as tags on IPS actions.

Actions represent the installable objects on a system. Actions are described in the manifest of a package. Every action consists primarily of its name and a key attribute. Together, these refer to a unique object as it follows a version history.

Variants and facets affect whether a particular action is selected or deselected for installation.

The following list shows some examples of facet and variant tags and their possible values.

true, false
true, false
true, false
true, false
sparc, i386, zos
true, false

Actions that are not tagged with facets or variants are included.

An action that is tagged with a variant that is not selected is excluded. An action that is tagged with one or more facets is excluded if none of the facets is selected.

A single action can have multiple facet and variant tags. An example of a component with multiple facet and variant tags is an architecture-specific header file that is used by developers.

Variants and facets are set at the image level. An image with a variant set to a particular property can only have actions that match that variant installed on it. For example, you cannot install an x86 package into a SPARC image.

System administrators can perform the following operations on facets and variants: