| Skip Navigation Links | |
| Exit Print View | |
|
Adding and Updating Oracle Solaris 11.1 Software Packages Oracle Solaris 11.1 Information Library |
| Skip Navigation Links | |
| Exit Print View | |
|
|
Adding and Updating Oracle Solaris 11.1 Software Packages Oracle Solaris 11.1 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.
Group and incorporation packages do not deliver content such as files, but they help you install sets of related packages.
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. See Relaxing Version Constraints Specified by Incorporations for related information.
The package named entire is a special incorporation package that constrains the versions of other incorporation packages.
 | Caution - Do not remove the package named entire. The 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 incorporation. Removing the entire package will result in an unsupported system. |
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.
Group package manifests specify group dependencies. Group packages deliver the packages named in those group dependencies unless those packages 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/amp package, for example, delivers the Apache web server, the MySQL database, and PHP. The group/system/solaris-desktop package delivers a set of packages suitable for a desktop system. The group/system/solaris-large-server package does not deliver desktop packages such as media tools and windowing themes. See Listing All Installable Packages in a Group Package for an example of how to list of all the packages that are delivered by a 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. When using IPS commands, you can use the smallest portion of the package name that uniquely identifies the package.
FMRI format:
scheme://publisher/package_name@version:dateTtimeZ
FMRI example:
pkg://solaris/driver/network/ethernet/bge@0.5.11,5.11-0.175.1.0.0.21.0:20120723T161616Z
pkg
solaris
If the publisher is specified, then the publisher name must be preceded by pkg:// or //.
driver/network/ethernet/bge
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 package version has four parts:
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.4.10.
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.
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:
The major or marketing development release build number. In this example, 0.175 indicates Oracle Solaris 11.
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, 1 indicates Oracle Solaris 11.1.
The Support Repository Update (SRU) number for this update release. SRUs include only bug fixes; they do not include new features. The Oracle Support Repository is available only to systems under a support contract.
This field is not currently used for Oracle Solaris packages.
The build number of the SRU, or the respin number for the major release.
The build number for the individual nightly builds.
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 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 set on the image and are tags set on actions within a package. Most variant tags can have various values. Facet tags set on an action can only have the value true. 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.
The following algorithm describes how the facets and variants set on the image affect whether a particular action is 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.
|