Overview of Solaris Patch Types and Dependencies

Lynne Thompson, November 2007

This document provides an overview of patch types. Also, this document describes the basic interrelationships between patches.

Definition of a Patch

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 README file.

Overview of Patch Types

This section describes the specific types of patches.

Table 1 Patch Types

Patch Type Description
Kernel patch (formerly known as Kernel Update [KU] patch) A generally-available standard patch. This patch is important because of the scope of change affecting a system. A Kernel patch changes the Solaris kernel and related core Solaris functionality. A reboot is required to activate the new Kernel version.
Temporary patch (T-patch) A patch that has been built and submitted for release but has not completed the full test and verification process.

Before being officially released, Solaris patches are structurally audited, functionally verified, and subjected to a system test process. Testing occurs when patches are in the “T-patch” state. After successfully completing the test process, the patches are officially released. For an overview of Sun's patch test coverage.

A T-patch might be made available to a customer involved in an active escalation to verify that the patch fixes the customer's problem. This type of patch is identified by a leading “T” in the patch ID, for example, T108528-14. The words “(Preliminary Patch - Not Yet Released)” appear on the first line of the patch README file. After the patch has been tested and verified, the T-patch designation is removed, and the patch is released.

Note - If you have a T-patch installed and then find that the patch is released at the same revision, there is no need to remove the T-patch and then install the released version. The released version and the T-patch are the same except for the README file.

Security T-patches The Security T-Patches section of the SunSolve site provides early access to patches that address security issues. See the Security T-Patch download section.

These patches are still in the T-patch stage, which means they have not completed the verification and patch testing process. The installation of Security T-patches is at the user's discretion and risk. Information about the issues addressed by Security T-patches and possible workarounds is available through the Free Security Sun Alert data collection. See the Sun Security Coordination Team page.

Rejuvenated patch Patches that become overly large or complex sometimes follow a process of “rejuvenation.” The rejuvenation process provides patches that incrementally install complex new functionality in relative safety. When a patch becomes a rejuvenated patch, no more revisions of the patch are created. Instead, further changes to the rejuvenated patch are delivered in a series of new patch IDs. These new patches depend upon and require the rejuvenated patch. If one of the new patches becomes complex over time, that patch could become a rejuvenated patch. For example, the Kernel patch is rejuvenated when needed.

The advantage of this process is that although a customer must install the complex patch once, future patches are much simpler to install.

For more details, see the SunSolve Patch Rejuvenation article.

Point patch A custom patch. This patch is provided to customers as a response to a specific problem encountered by that customer. Point patches are only appropriate for the customers for whom the patches have been delivered. These patches are typically created for one customer, because the majority of customers would consider the “fix” worse than the issue the fix is addressing. These patches are created on a branch of the Solaris source code base and are not folded back into the main source base.

Access to a point patch is restricted and should only be installed after consultation with Sun support personnel.
Restricted patch (R-patch) A rare patch that has a special characteristic. An R-patch locks the package modified. This lock prevents subsequent modification of the package by other patches.

R-patches are used in circumstance similar to point patches. Like a point patch, an R-patch is only appropriate for the customer for whom the patches have been delivered. These patches are created on a branch of the Solaris source code base and are not folded back into the main source base.

Before the “official” standard patch can be applied, an R-patch must be manually removed.
Interim Diagnostic Relief (IDR) An IDR provides software to help diagnose a customer issue, or provide preliminary, temporary relief for an issue. An IDR is provided in a patch format similar to an R-patch, but because an IDR does not provide a final fix to the issue, an IDR is not a substitute for an actual patch. The official patch or patches should replace the IDR as soon as practical.
Interim Security Relief (ISR) A patch that fixes a public security issue. This patch is a type of IDR. An ISR is an early stage fix that provides protection to a security vulnerability that is publicly known. An ISR has not completed the review, verification, and testing processes. The installation of an ISR is at the user's discretion and risk.
Nonstandard patch A patch that cannot be installed by using the patchadd command. A nonstandard patch is not delivered in package format. This patch must be installed according to the “Special Install Instructions” specified in the patch README file. A nonstandard patch typically delivers firmware or application software fixes.
Withdrawn patch If a released patch is found to cause serious issues, the patch is removed from SunSolve.

  • The patch is no longer available for download.

  • The README remains on SunSolve. The README is changed to state that the patch is withdrawn and a brief statement is added about the problem and why the patch was removed.

  • The patch is logged for a year in the list of withdrawn patches.

  • A Sun Alert is released to notify customers about the withdrawn patch issue. The Sun Alert specifies any actions that should be taken by customers who have the withdrawn patch installed on their system.

    The Sun Alert appears in the list of recently published Sun Alerts.

Interactive patches A patch that requires user interaction in order to be installed. The patch must be installed according to the Special Install Instructions specified in the patch README file.
Update releases and script patches Sun periodically releases updates to the current version of the Solaris distribution. These releases are sometimes known as an “Update” release. An Update release is a complete distribution and is named with a date designation, for example, Solaris 10 6/06.

An Update release consists of all the packages that made up the original release, such as Solaris 10 3/05, with all accumulated patches pre-applied and includes any new features that are qualified for inclusion.

The process of pre-applying patches involves some patches that do not get released. Therefore, a system with an Update release installed appears to have some patches applied that cannot be found on SunSolve. These patches are called script patches. Script patches do not deliver bug fixes or new features, but deliver fixes that are a result of issues with the creation of the image. As a result, script patches are not made available for customers, because they are not required outside of creating the Update release.

Patch Characteristics

The following sections provide basic information about patch characteristics.

Keywords in the README File

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.

Patch Metadata

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 pkginfo and pkgmap files.

Patch Metadata for Non-Global Zones

Patches contain Solaris Zones specific metadata to ensure the correct patching of a Zones environment.

Patch Dependencies (Interrelationships)

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

pkginfo file:

  • The SUNW_REQUIRES field identifies patch dependencies. These prerequisite patches must be installed before this patch can be installed.

  • The SUNW_OBSOLETES field identifies patches whose contents have been accumulated into this patch. This new patch obsoletes the original patches.

  • The 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 patchadd and 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 README file.

SUNW_REQUIRES Field for Patch Dependencies

The 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_OBSOLETES Field for Patch Accumulation and Obsolescence

The 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 pkginfo file.

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_INCOMPAT Field 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.

Where to Find More Information About Patching

Table 2 Patching References

Description Information
Related resources: