This section defines terms and concepts related to IPS.
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.4 or the pkg(7) 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.
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 22.214.171.124, 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.
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.
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.
The following rules apply to matching package names and versions in IPS command operands:
Package names. You can use the smallest portion of the package name that uniquely identifies the package. You can use the ? and * characters as glob(3C)-style wildcards in the package name to match one or more packages.
Package versions. If you specify a version, you can omit components from the right hand side of the version string. You can use the * character as a wildcard to match a whole component of the version string. A * character cannot be used to match a partial component. A single * character cannot match more than one component. The ? cannot be used in a version string.
The following examples illustrate package matching:
Match any installed package that has jre anywhere in the name:
$ pkg list '*jre*' NAME (PUBLISHER) VERSION IFO runtime/java/jre-8 126.96.36.199.12 i--
Match all installed packages with java anywhere in the name, any component version, and 11.4 branch version:
Notice the one-character difference between the following command and the previous command:
$ pkg list '*java*@*11.4' pkg list: Illegal FMRI '*java*@*11.4': Bad Version: *11.4
An asterisk * cannot match a partial version component or more than one version component:
$ pkg list '*email@example.com.*.10.0' pkg list: no packages matching the following patterns are installed: *firstname.lastname@example.org.*.10.0 $ pkg list '*java*@*.10.0' pkg list: no packages matching the following patterns are installed: *java*@*.10.0
The scheme for every IPS package FMRI is pkg. In the following example package FMRI for the compliance security compliance framework, solaris is the publisher, security/compliance is the package name, and 11.4-188.8.131.52.1.10.1:20180702T144054Z is the version:
If the publisher is specified, then the publisher name must be preceded by pkg:// or //.
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.
The version string consists of the following three parts, and the format of the time stamp is dateTtimeZ:
For components that are tightly bound to the operating system, the component version number is minor.update. Other components, such as FOSS components, have their own version numbers. In the following example, the version number of the web/server/apache-24 package is 2.4.25:
The component version number is the same as the “Version” in pkg info output.
The branch version, if present, must follow a hyphen (-). The branch version string is the same as the “Branch” in pkg info output.
Oracle Solaris packages show the following information in the branch version portion of the version string of a package FMRI:
The minor portion of major.minor that is output by the uname -r command.
The update release number for this Oracle Solaris release.
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.
This value is used internally.
This value is used internally.
The build number of the SRU, or the respin number for the release.
The build number for the individual nightly builds.
If the package is an Interim Diagnostic or Relief (IDR) update, then the component_version-branch_version of the package FMRI is just a single field. For example, the FMRI for idr1929 is pkg://solaris/idr1929@4:20160216T222617Z; the complete component_version-branch_version part of the version is simply 4. 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 time stamp must follow a colon (:). The time stamp is the time the package was published in ISO-8601 basic format: YYYYMMDDTHHMMSSZ.
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.
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(7) man page for more information.
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.4 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.
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.