| Skip Navigation Links | |
| Exit Print View | |
|
Oracle Solaris 11 Express Image Packaging System Guide Oracle Solaris 11 Express 11/10 |
| Skip Navigation Links | |
| Exit Print View | |
|
|
Oracle Solaris 11 Express Image Packaging System Guide Oracle Solaris 11 Express 11/10 |
1. Introduction to the Image Packaging System
2. IPS Graphical User Interfaces
This section defines terms and concepts that are used in the remainder of this guide.
IPS manages software in units of packages. An IPS package is a collection of directories, files, links, drivers, dependencies, groups, users, and license information in a defined format. This collection represents the installable objects of a package. Packages have attributes such as package name and description.
You can use commands to view information about a package, or you can view the manifest for a package.
IPS supports both IPS packages and SVR4 packages.
There is no standard on-disk format for an IPS package. IPS does not have an equivalent for .rpm, SVR4 package, or .nbm files.
Each IPS package is represented by a Fault Management Resource Identifier (FMRI).
The FMRI includes descriptive information about the package, such as the package name, version information, and date, as shown in the following example:
pkg://solaris/library/libc@5.11,5.11-0.75:20071001T163427Z
Scheme: pkg
Publisher: solaris
Category: library
Package name: libc
Version string
Component version: 5.11
Build version: 5.11
Branch version: 0.75
Time the package was published, in ISO-8601 basic format: 20071001T163427Z
A publisher is a forward domain name that identifies a person, group of persons, or an organization that publishes one or more packages.
A repository is a location where clients publish and retrieve packages. The location is described by a Universal Resource Identifier (URI). A repository is also called a depot server.
A repository contains packages from a single publisher.
A publisher can publish to multiple repositories.
Multiple repositories can contain packages with the same name. Publishers can be configured into a preferred search order in each image. When a package is selected for installation, the preferred publisher is searched first for that package, then the next most preferred publisher is searched until the package is found or all publishers have been searched.
A repository URI is not required to contain the name of the publisher. For example, the solaris publisher publishes to repositories hosted at oracle.com.
A repository has an origin and zero or more mirrors.
The repository origin is the location of a package repository that contains both package metadata (package manifests and catalogs) and package content (package files).
A mirror is a location of a package repository that contains only package content.
Mirrors provide a subset of the data that origins provide. Mirrors can be used only for downloading package files. Package metadata is downloaded from the origin. IPS clients access the origin to obtain a publisher's catalog, even when the clients download package content from a mirror.
An image is a location where packages can be installed.
An image can be one of three types:
Full images are capable of providing a complete system.
Partial images are linked to a full image (the parent image), but do not provide a complete system on their own.
User images contain only relocatable packages.
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 is automatically created when you perform one of the following operations:
Install the Oracle Solaris OS.
Update particular key system packages such as some drivers and other kernel components. This can happen when you install, uninstall, update, change variant, or change facet.
Use the beadm create command.
Often a new BE is created when you execute the pkg update command to update all packages that have updates available.
If a new BE is created, the system performs the following steps:
Creates a clone of the current BE that is a bootable image.
The clone BE includes everything hierarchically under the main root dataset of the original BE. Shared file systems are not under the root dataset and are not cloned. Instead, the BE accesses the original shared file systems.
Updates the packages in the clone BE, but does not update any packages in the current BE.
If zones are configured in the current BE, these existing zones are configured in the new BE. However, packages are not installed or updated in these zones. You must manually update each zone in the new BE.
Sets the new BE as the default boot choice the next time the system is booted. The current BE remains as an alternate boot choice.
Several IPS commands provide the following options to support BE creation. Check the applicable man page.
Assign BEname to the newly created BE. This option is ignored if a new BE is not created.
Do not create a new BE, even if a new BE is required by the components to be installed. If this option is specified and a new BE is required, the operation is not performed.
Create a new BE, even if a new BE is not required.
If a new BE is required but not enough space is available to create a new BE, you might be able to delete existing unneeded BEs. For more information about BEs, see the Managing Boot Environments With Oracle Solaris 11 Express guide.
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. Both variants and facets appear as tags on IPS actions.
Actions represent the installable objects on a system. Actions are described in the manifest of a package. Every action consists primarily of its name and a key attribute. Together, these refer to a unique object as it follows a version history.
Variants and facets affect whether a particular action is selected or deselected for installation.
The following list shows some examples of facet and variant tags and their possible values.
|
Actions that are not tagged with facets or variants are included.
An action that is tagged with a variant that is not selected is excluded. An action that is tagged with one or more facets is excluded if none of the facets is selected.
Variant tags are evaluated with AND. If any of the variant tags does not match, the action is not installed.
Facet tags are evaluated with OR. If any of the facet tags match, the action is not excluded.
A single action can have multiple facet and variant tags. An example of a component with multiple facet and variant tags is an architecture-specific header file that is used by developers.
Variants and facets are set at the image level. An image with a variant set to a particular property can only have actions that match that variant installed on it. For example, you cannot install an x86 package into a SPARC image.
System administrators can perform the following operations on facets and variants:
Display the values of all variants or facets set on the current image.
Change variants and facets in the current image. This operation probably will update packages and might require a new BE.
|