Lynne Thompson, November 2007
This document provides an overview of patch types. Also, this document describes the basic interrelationships between patches.
A patch is an accumulation of fixes to a known problem or to a potential problem within the operating system or other supported software. A patch can also provide a new feature or an enhancement to a particular software release. A patch consists of files and directories that replace or update existing files and directories.
Most Solaris patches are delivered as a collection of sparse SVR4 packages. A patch can contain one or more sparse packages. A sparse package contains only those objects that have been altered since Solaris first delivered the package version in a distribution. When code changes are provided with sparse packages, these packages enable small patches rather than redistributing complete, but large, packages. Sparse packages minimize the changes made to the customer's environment.
Each patch is identified by a patch identification number (patch ID). The patch ID consists of a six-digit base identifier and a two-digit revision number of the form xxxxxx-yy.
Patches are cumulative. Later revisions contain all of the functionality delivered in previous revisions. For example, patch 123456-02 contains all the functionality of patch 123456-01 plus the new bug fixes or features that have been added in Revision 02. The changes are described in the patch
This section describes the specific types of patches.
The following sections provide basic information about patch characteristics.
Keywords are provided to enable users to identify which patches might be applicable to their environment. The most important keyword is “Security.” Security designates that the patch includes a security fix and therefore should be considered with greater urgency. Other keywords might include the affected subsystem, hardware platform, or user commands.
Patches have associated metadata that describes attributes of the patch. Metadata includes special handling requirements such as “reboot after installation” or “single-user mode installation required.” These attributes are translated into text in the
README file, which should be read.
The Solaris patch utilities also utilize the metadata contained in the
Patches contain Solaris Zones specific metadata to ensure the correct patching of a Zones environment. Detailed information can be found in the following references:
The functionality delivered in a patch, either bug fixes or new features, might have interrelationships with the functionality delivered in other patches.
These interrelationships are determined by three fields in the package's
SUNW_REQUIRES field identifies patch dependencies. These prerequisite patches must be installed before this patch can be installed.
SUNW_OBSOLETES field identifies patches whose contents have been accumulated into this patch. This new patch obsoletes the original patches.
SUNW_INCOMPAT field identifies patches that are incompatible with this patch, and therefore cannot be installed on the same system.
These fields are used by the Solaris
patchrm commands to automatically ensure the consistency of the target system that is being patched. These fields are also translated into human readable form in the patch
SUNW_REQUIRESField for Patch Dependencies
SUNW_REQUIRES identifies patch dependencies. The functionality delivered in a patch might have a code dependency on the changes or functionality that is delivered in other patches. Therefore, one patch requires one or more other patches to function correctly. If a patch depends on one or more patches, the patch specifies the required patches in the
SUNW_REQUIRES field in the
pkginfo file in the patch's packages. This information is also be reflected in the
README file. Such prerequisite patches must be installed before this patch can be installed.
The dependency requirement can only work one way. If Patch A requires Patch B, Patch B cannot require Patch A. Because patches are cumulative, if Patch A-01 requires Patch B-01, any revision of Patch B greater than or equal to -01 also satisfies the requirement.
If other types of dependencies exist, they are specified in the patch README file and can include the following:
Conditional dependencies indicate that a hard-coded patch dependency that occurs only under specific conditions. For example, only if CDE 1.3 is installed on the target system.
Soft dependencies indicate that other patches are required to completely deliver a particular bug fix or feature, but the system remains in a consistent state without the other patches.
SUNW_OBSOLETESField for Patch Accumulation and Obsolescence
SUNW_OBSOLETES field identifies patch accumulation and obsolescence. Sometimes bug fixes or new features cause two or more existing patches to become closely intertwined. For example, a bidirectional, hard-code dependency might exist between two patches. In such cases, it might be necessary to accumulate the functionality of two or more patches into one patch, thereby rendering the other patch or patches obsolete. The patch into which the other patch's functionality is accumulated specifies the patch ID or IDs of the patch or patches that it has obsoleted. This information is in the
SUNW_OBSOLETES field in the
pkginfo files delivered in the patch's sparse packages. This declaration is called explicit obsolescence.
The patch accumulation can only work one way. That is, if Patch A accumulates Patch B, Patch A now contains all of Patch B's functionality. Patch B is now obsolete. No further revision of Patch B will be generated.
Due to the cumulation of patches, a later revision of a patch “implicitly” obsoletes earlier revisions of the same patch. Patches that are implicitly obsoleted are not flagged in the
SUNW_OBSOLETES field. For example, Patch A-Revision xx does not need to explicitly obsolete Patch A-Revision x-1 with a
SUNW_OBSOLETES entry in the
Note - For Solaris 10 and Solaris 10 releases (after August 2007), a patch might be released that contains no new changes. This patch might state that it obsoletes another patch that was released some months earlier. This is a consequence of the Solaris Update patch creation process. If you have the obsoleted patch installed, and the new patch does not list any new changes, you do not need to install this new patch.
For example, the Solaris 10
timezones patch 122032-05 was obsoleted by patch 125378-02. If you already have 122032-05 installed, there is no need to install 125378-02, because patch 125378-02 does not deliver any new changes.
SUNW_INCOMPATField for Incompatibility
Occasionally, two or more patches are incompatible with one another. Incompatibility is frequently defined in point patches and IDRs. Incompatibility is rarely defined in regular patches. An incompatibility is specified in the
SUNW_INCOMPAT field in the
pkginfo file in the sparse package of one or both of the patches.
Patch incompatibility is two way. If Patch A or Patch B specifies an incompatibility with the other patch, only one of the patches can be installed on the target system. For example, if Patch A is already installed on the target system and Patch B is incompatible with it, the patch install utility
patchadd will not allow Patch B to be installed. If Patch B must be installed, Patch A must first be removed.
Both patches or an incompatible pairing do not have to define the incompatibility. Typically, a point patch or an IDR defines an incompatibility, because these types of patches are from nonstandard code branches.
Unless otherwise licensed, code in all technical manuals herein (including articles, FAQs, samples) is provided under this License.
More Systems Downloads