This appendix describes how Oracle uses IPS features to package the Oracle Solaris OS, and how the various dependency types are used to define working package sets for the OS.
This appendix provides another concrete example of using IPS to manage a complex set of software.
Package Identifier: FMRI described the pkg.fmri attribute and the different components of the version field, including how the version field can be used to support different models of software development. This section explains how the Oracle Solaris OS uses the version field, and provides insight into the reasons that a fine-grained versioning scheme can be useful. In your packages, you do not need to follow the same versioning scheme that the Oracle Solaris OS uses.
The meaning of each part of the version string in the following sample package FMRI is given below:
pkg://solaris/system/[email protected],5.11-0.175.1.0.0.2.1:20120919T082311Z
Component version. For packages that are part of the Oracle Solaris OS, this is the OS major.minor version. For other packages, this is the upstream version. For example, the component version of the following Apache Web Server package is 2.2.22:
pkg:/web/server/[email protected],5.11-0.175.1.0.0.2.1:20120919T122323Z
Build version. This is used to define the OS release that this package was built for. The build version should always be 5.11 for packages created for Oracle Solaris 11.
Branch version. Oracle Solaris packages show the following information in the branch version portion of the version string of a package FMRI:
Major release number. The major or marketing development release build number. In this example, 0.175 indicates Oracle Solaris 11.
Update release number. 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.
SRU number. 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.
Reserved. This field is not currently used for Oracle Solaris packages.
SRU build number. The build number of the SRU, or the respin number for the major release.
Nightly build number. The build number for the individual nightly builds.
Time stamp. The time stamp was defined when the package was published.
Oracle Solaris is delivered by a set of packages, with each group of packages constrained by an incorporation.
Each incorporation roughly represents the organization that developed each group of packages, though there are some cross-incorporation dependencies within the packages themselves. The following incorporation packages are in Oracle Solaris (pkg list *incorporation):
pkg:/consolidation/SunVTS/SunVTS-incorporation pkg:/consolidation/X/X-incorporation pkg:/consolidation/admin/admin-incorporation pkg:/consolidation/cacao/cacao-incorporation pkg:/consolidation/cde/cde-incorporation pkg:/consolidation/cns/cns-incorporation pkg:/consolidation/dbtg/dbtg-incorporation pkg:/consolidation/desktop/desktop-incorporation pkg:/consolidation/desktop/gnome-incorporation pkg:/consolidation/gfx/gfx-incorporation pkg:/consolidation/install/install-incorporation pkg:/consolidation/ips/ips-incorporation pkg:/consolidation/java/java-incorporation pkg:/consolidation/jdmk/jdmk-incorporation pkg:/consolidation/l10n/l10n-incorporation pkg:/consolidation/ldoms/ldoms-incorporation pkg:/consolidation/man/man-incorporation pkg:/consolidation/nspg/nspg-incorporation pkg:/consolidation/nvidia/nvidia-incorporation pkg:/consolidation/osnet/osnet-incorporation pkg:/consolidation/sfw/sfw-incorporation pkg:/consolidation/sic_team/sic_team-incorporation pkg:/consolidation/solaris_re/solaris_re-incorporation pkg:/consolidation/sunpro/sunpro-incorporation pkg:/consolidation/ub_javavm/ub_javavm-incorporation pkg:/consolidation/userland/userland-incorporation pkg:/consolidation/vpanels/vpanels-incorporation pkg:/consolidation/xvm/xvm-incorporation
Each of these incorporations includes the following information:
Package metadata.
Dependencies of type incorporate, sometimes with variant.arch variants to denote dependencies that are specific to a given architecture. See incorporate Dependency and Mutually Exclusive Software Components for more information about incorporate dependencies and variant.arch variants.
A license action to ensure that a license is displayed when the incorporation is installed. See License Actions for more information about license actions.
Each package delivered on the system contains a require dependency on one of these incorporations. See require Dependency for more information.
Oracle Solaris also includes a special incorporation named entire. The entire incorporation constrains all other incorporations to the same build by including both require and incorporate dependencies on each incorporation package. In this way, the entire incorporation defines a software surface such that all packages are upgraded as a single group.
Some of the incorporations listed above use facet.version-lock.* facets to enable the administrator to use the pkg change-facet command to relax the constraint to the incorporation for the specified packages. See Relaxing Constraints on Installable Package Versions for more information.
For example, the pkg:/consolidation/userland/userland-incorporation package contains the following facet.version-lock.* definitions:
.. depend type=incorporate \ fmri=pkg:/library/python-2/[email protected] \ facet.version-lock.library/python-2/subversion=true depend type=incorporate \ fmri=pkg:/library/security/[email protected] \ facet.version-lock.library/security/libassuan=true depend type=incorporate \ fmri=pkg:/library/security/openssl/[email protected] \ facet.version-lock.library/security/openssl/openssl-fips-140=true depend type=incorporate fmri=pkg:/mail/[email protected] \ facet.version-lock.mail/fetchmail=true depend type=incorporate \ fmri=pkg:/network/chat/[email protected] \ facet.version-lock.network/chat/ircii=true depend type=incorporate \ fmri=pkg:/print/cups/filter/[email protected] \ facet.version-lock.print/cups/filter/foomatic-db-engine=true depend type=incorporate \ fmri=pkg:/print/filter/[email protected] \ facet.version-lock.print/filter/gutenprint=true depend type=incorporate fmri=pkg:/runtime/[email protected] \ facet.version-lock.runtime/erlang=true ..
The entire package also contains version-lock facets. In this case, the facets allow specified incorporations to be removed from the entire incorporation. However, this can result in a system that is not covered by support. Those packages should only be unlocked on advice from Oracle support personnel.
Oracle Solaris defines several group packages that contain group dependencies. See group Dependency for more information about group dependencies. These group packages enable convenient installation of common sets of packages.
The following group packages are provided in Oracle Solaris:
$ pkg list -Has 'pkg:/group/*' group/feature/amp AMP (Apache, MySQL, PHP) Deployment Kit for Oracle Solaris group/feature/developer-gnu GNU Development Tools for Oracle Solaris group/feature/multi-user-desktop Oracle Solaris Multi User Desktop group/feature/storage-avs Sun StorageTek Availability Suite group/feature/storage-nas Network attached storage group package group/feature/storage-server Multi protocol storage server group package group/feature/trusted-desktop Oracle Solaris Trusted Desktop group/system/management/rad/rad-client-interfaces RAD client bindings group package group/system/management/rad/rad-server-interfaces RAD server modules group package group/system/solaris-auto-install Oracle Solaris Automated Installer Client group/system/solaris-core-platform Oracle Solaris Core Platform group/system/solaris-desktop Oracle Solaris Desktop group/system/solaris-large-server Oracle Solaris Large Server group/system/solaris-minimal-server Oracle Solaris Minimal Server group/system/solaris-small-server Oracle Solaris Small Server
The solaris-small-server group package is installed by the default AI manifest that is used to install non-global zones (/usr/share/auto_install/manifest/zone_default.xml). See solaris(5) for more information.
This section describes general and Oracle Solaris action attributes and Oracle Solaris attribute tags.
The following attributes are not necessary for correct package installation, but having a shared convention reduces confusion between publishers and users.
See Set Actions for information about the info.classification attribute. See a list of classifications in Appendix A, Classifying Packages.
A list of additional terms that should cause this package to be returned by a search.
A human readable string that describes the entity that provides the package. This string should be the name, or name and email of an individual, or the name of an organization.
A URL associated with the entity that provides the package.
A human readable string that describes the entity that creates the software. This string should be the name, or name and email of an individual, or the name of an organization.
A URL associated with the entity that creates the software delivered in the package.
A URL to the source code bundle for the package, if appropriate.
A URL to the source code repository for the package, if appropriate.
A changeset ID for the version of the source code contained in info.repository-url.
One or more case identifiers (for example, PSARC/2008/190) associated with the ARC case (Architecture Review Committee) or cases associated with the component delivered by the package.
One or more FMRIs that represent SMF services delivered by this package. These attributes are automatically generated by pkgdepend for packages that contain SMF service manifests. See the pkgdepend (1) man page.
To provide additional metadata for a package, use an organization-specific prefix on the attribute name. Organizations can use this method to provide additional metadata for packages developed in that organization or to amend the metadata of an existing package. To amend the metadata of an existing package, you must have control over the repository where the package is published. For example, a service organization might introduce an attribute named service.example.com,support-level or com.example.service,support-level to describe a level of support for a package and its contents.
Specifies which actions in a package can be installed in a non-global zone, in the global zone, or in either a non-global or the global zone. See Chapter 10, Handling Non-Global Zones for more information.