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

IPS Design Goals

Software Self-Assembly

Tools for Software Self-Assembly

Atomic Software Objects

Configuration Composition

Actuators and SMF Services

Examples of Software Self-Assembly in Oracle Solaris

Apache Web Server

Multiple Packages Delivering Configuration Fragments

IPS Package Lifecycle

IPS Terminology and Components

Installable Image

Package Identifier: FMRI

Package Publisher

Package Name

Package Version

Package Content: Actions

File Actions

Directory Actions

Link Actions

Hardlink Actions

Set Actions

Driver Actions

Depend Actions

License Actions

Legacy Actions

Signature Actions

User Actions

Group Actions

Package Repository

2.  Packaging Software With IPS

3.  Installing, Removing, and Updating Software Packages

4.  Specifying Package Dependencies

5.  Allowing Variations

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

IPS Package Lifecycle

This section provides high-level descriptions of each state in the IPS package lifecycle. For best results, both package developers and system administrators should understand the various phases of the package lifecycle.


Packages can be created by anyone. IPS does not impose any particular software build system or directory hierarchy on package authors. For details about package creation, see Chapter 2, Packaging Software With IPS. Aspects of package creation are discussed throughout the remaining chapters of this guide.


Packages are published to an IPS repository, either to an HTTP location or to the file system. A published package can also be converted to a .p5p package archive file. To access software from an IPS repository, the repository can be added to the system using the pkg set-publisher command, or the repository can be accessed as a temporary source by using the -g option with pkg commands. Examples of package publication are shown in Chapter 2, Packaging Software With IPS.


Packages can be installed on a system, either from an IPS repository accessed over http://, https://, or file:// URLs, or from a .p5p package archive. Package installation is described in more detail in Chapter 3, Installing, Removing, and Updating Software Packages.


Updated versions of packages might become available, either published to an IPS repository, or delivered as a new .p5p package archive. Installed packages can then be brought up to date, either individually, or as part of an entire system update.

Note that IPS does not use the same concept of “patching” that the SVR4 packaging system did. All changes to IPS packaged software are delivered by updated packages.

Package updates are performed in much the same way as package installations, but the packaging system is optimized to install only the changed portions delivered by an updated package. Package updating is described in more detail in Chapter 3, Installing, Removing, and Updating Software Packages.


During the life of a package, you might want to rename the package. A package might be renamed for organizational reasons or to refactor packages. Examples of package refactoring include combining several packages into a single package or breaking a single package into multiple smaller packages.

IPS gracefully handles content that moves between packages. IPS also allows old package names to persist on the system, automatically installing the new packages when a user asks to install a renamed package. Package renaming is described in more detail in Chapter 10.


Eventually a package might reach the end of its life. A package publisher might decide that a package will no longer be supported, and that it will not have any more updates made available. IPS allows publishers to mark such packages as obsolete.

Obsolete packages can no longer be used as a target for most dependencies from other packages, and any packages upgraded to an obsolete version are automatically removed from the system. Package obsoletion is described in more detail in Renaming, Merging and Splitting Packages.


Finally, a package can be removed from the system if no other packages have dependencies on it. Package removal is described in more detail in Chapter 3, Installing, Removing, and Updating Software Packages.