| Skip Navigation Links | |
| Exit Print View | |
|
Adding and Updating Oracle Solaris 11 Software Packages Oracle Solaris 11 Information Library |
| Skip Navigation Links | |
| Exit Print View | |
|
|
Adding and Updating Oracle Solaris 11 Software Packages Oracle Solaris 11 Information Library |
1. Introduction to the Image Packaging System
Fault Management Resource Identifiers
Publishers, Repositories, and Package Archives
2. IPS Graphical User Interfaces
3. Getting Information About Software Packages
This section defines terms and concepts that are used in the remainder of this guide.
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 1.4.3.7, 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.
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.
Format:
scheme://publisher/package_name@version:dateTtimeZ
Example:
pkg://solaris/editor/vim@7.3.254,5.11-0.174.0.0.0.0.504:20110921T002716Z
pkg
solaris
If the publisher is specified, then the publisher name must be preceded by pkg:// or //.
editor/vim
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:
7.3.254
For components tightly bound to the operating system, this is usually the value of uname -r for that version of the operating system.
5.11
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.
0.174.0.0.0.0.504
The branch version must follow a hyphen (-). The branch version provides vendor-specific information.
20110921T002716Z
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 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.
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.
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.
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.
Actions with no facet or variant tags are always installed.
Actions with facet tags are installed unless all of the facets or facet patterns matching the tags are set to false on the image. If any facet is set to true or is not explicitly set (true is the default), then the action is installed.
Actions with variant tags are installed only if the values of all the variant tags are the same as the values set in the image.
Actions with both facet and variant tags are installed if both the facets and the variants allow the action to be installed.
To view or modify the values of the facets and variants set on the image, see Controlling Installation of Optional Components.
|