Adding and Updating Software in Oracle^® Solaris 11.3

IPS Concepts

This section defines terms and concepts related to IPS.

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 Package Content: Actions in Packaging and Delivering Software With the Image Packaging System in Oracle Solaris 11.3 or the pkg(5) man page for descriptions of package actions.

Constraint packages and group packages do not deliver content such as files. Constraint and group packages specify dependencies that help you install sets of related packages.

Constraint Packages

A constraint package specifies incorporate dependencies to define a surface in the package version space that is compatible. Constraint packages are used to define sets of software packages that are built together and are not separately versioned. The incorporate dependency is heavily used in Oracle Solaris to ensure that compatible versions of software are installed together.

An incorporate dependency constrains the versions of that package that can be installed in this image. A package is not installed just by being named as an incorporate dependency. If the package is installed by some other means (for example, it is also a require dependency or you explicitly install the package), then only a version prescribed by the incorporate dependency can be installed. For example, if a package specified as an incorporate dependency in an installed constraint package has a version value of 1.4.3, then no version of that package can be installed that has a version value less than 1.4.3 or greater than or equal to 1.4.4. A version of the package with a version value of 1.4.3.7, for example, could be installed.

Packages named as incorporate dependencies in the constraint package might themselves be constraint packages. In this way, many packages can be affected by a constraint package even if they are not named in the manifest of the constraint package. Packages whose installation is affected by a constraint package are constrained by that constraint package. Updating a constraint package A-constraint that has an incorporate dependency on the constraint package B-constraint results in also updating B-constraint and all the other packages that are constrained by B-constraint. An attempt to update B-constraint separately from A-constraint could result in an error.

Constraint packages force the constrained packages to upgrade synchronously to help maintain a working, supportable image. In general, you should not install or update a package that is an incorporate dependency of a constraint package. Instead, you should update the constraint package. A constrained package could be uninstalled, but if the constrained package is installed or updated, the version is constrained. See Relaxing Version Constraints Specified by Constraint Packages for related information.

The pkg:/entire package is a special constraint package that specifies incorporate dependencies on many other constraint packages to constrain the versions of most of the system software installed in the image.

---

Caution  -  Do not remove the pkg:/entire package. The pkg:/entire package constrains system package versions so that the resulting set of packages is a supportable image. Proper system update and correct package selection depend on this constraint package. Removing the pkg:/entire package will result in an unsupported system.

---

Group Packages

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

A group package delivers the packages named in its group dependencies unless those packages are already installed or are on the avoid list. See Avoiding Installing Some Packages in a Group Package for information about the avoid list of an image.

The group/feature/storage-server package, for example, delivers drivers, services, file systems, I/O components, libraries, and utilities related to storage if they are not already installed. The group/system/solaris-minimal-server package delivers the set of packages required for the minimum supported Oracle Solaris environment. See Listing All Installable Packages in a Group Package for an example of how to list all of the packages that are delivered by a group package.

Uninstalling a group package does not necessarily uninstall all the packages named in its group dependencies. Packages that are required by other software that is still installed will not be uninstalled when you uninstall the group package.

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:

scheme://publisher/name@version

The scheme, publisher, and version string are optional. In IPS command operands, you can use the smallest portion of the package name that uniquely identifies the package, and you can use the ? and * characters as glob(3C)-style wildcards to match one or more packages.

The scheme for every IPS package FMRI is pkg. In the following example package FMRI for the suri storage library, solaris is the publisher, system/library/storage/suri is the package name, and 0.5.11,5.11-0.175.3.0.0.19.0:20150329T164922Z is the version:

pkg://solaris/system/library/storage/suri@0.5.11,5.11-0.175.3.0.0.19.0:20150329T164922Z

Scheme

pkg

Publisher

solaris

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

Package name

system/library/storage/suri

Package names are hierarchical with an arbitrary number of components separated by forward slash (/) characters. In IPS commands, leading components of package names can be omitted if the package name that is used in the command 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.

Version

The version string consists of the following four parts, and the format of the time stamp is dateTtimeZ:

component_version,release-branch_version:time_stamp

Component version: 0.5.11

For components tightly bound to the operating system, the component version usually includes the value of uname -r for that version of the operating system. For a component with its own development lifecycle, the component version is a dotted release number, such as 2.2.29.

Release: 5.11

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

Branch version: 0.175.3.0.0.19.0

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

Oracle Solaris packages show the following information in the branch version portion of the version string of a package FMRI:

Major release number: 0.175

The major or marketing development release build number. In this example, 0.175 indicates Oracle Solaris 11.

Update release number: 3

The update release number for this Oracle Solaris release. The update value is 0 for the first customer shipment of an Oracle Solaris release, 1 for the first update of that release, 2 for the second update of that release, and so forth. In this example, 3 indicates Oracle Solaris 11.3.

SRU number: 0

The Support Repository Update (SRU) number for this update release. SRUs are approximately monthly updates that fix bugs, fix security issues, or provide support for new hardware. The Oracle Support Repository is available only to systems under a support contract.

Reserved: 0

This field is not currently used for Oracle Solaris packages.

Release or SRU build number: 19

The build number of the SRU, or the respin number for the major release.

Nightly build number: 0

The build number for the individual nightly builds.

If the package is an Interim Diagnostic or Relief (IDR) update, then the branch version of the package FMRI contains the following two additional fields. IDRs are package updates that help diagnose customer issues or provide temporary relief for a problem until a formal package update is issued. See Installing an IDR Custom Software Update for more information about IDRs. The following examples are for idr824, which has FMRI pkg://solaris/idr824@4,5.11:20131114T034951Z and contains packages such as pkg:/system/library@0.5.11-0.175.1.6.0.4.2.824.4:

IDR: 824

The name of the IDR.

IDR ID: 4

The version of the IDR.

Time stamp: 20150329T164922Z

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 a match of the specified package FMRI pattern 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 that install and update packages from a mirror repository must still download metadata from an origin repository. 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. See “Publishers and Repositories” in the pkg(5) man page for more information.

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 a bootable instance of an image. You can maintain multiple BEs on a physical or virtual system, and each BE can have different software versions installed, including different operating system versions. 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. Whether a new BE is created automatically depends on image policy as described in Boot Environment Policy Image Properties. You can also explicitly create a new BE by specifying options described in Boot Environment Options. See Creating and Administering Oracle Solaris 11.3 Boot Environments for information about how to use the beadm command to create a new BE.

Packages can only be installed into file systems that are part of a BE. For example, on a default Oracle Solaris 11 installation, only datasets under rpool/ROOT/BEname/ are supported for package operations.

An Oracle Solaris Zone is another example of an image. A non-global zone is a virtualized operating system environment created within an instance of the Oracle Solaris operating system called the global zone. The global zone is the parent image, and non-global zones within that global zone are child images of that global zone. In IPS command output, non-global zones are sometimes called linked images because they are linked to their parent global zone image.

IPS commands executed in a global zone can affect non-global zones as described in Working with Non-Global Zones. IPS commands executed in a global zone do not affect kernel zones (solaris-kz branded zones) or Oracle Solaris 10 zones (solaris10 branded zones). In this guide, “non-global zone” means a solaris branded Oracle Solaris 11 non-global zone. See Introduction to Oracle Solaris Zones for information about zones.

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, an optional component is called a facet and a mutually exclusive component is called a variant.

Facets and variants are special properties set on the image. Facets and variants are also tags set on actions in a package manifest. 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. For example, if you set a particular locale facet to false in the image, any file actions that specify that facet will not be installed, and currently installed file actions that specify that facet are uninstalled.

For more information about facets and variants, including how to view or modify the values of the facets and variants set on the image, see Controlling Installation of Optional Components.