[Top] [Prev] [Next] [Bottom]

Chapter 9: Managing Internal Patches

A patch is a fix of an error within a product version. A fix is made so that the product files including errors are replaced by corrected versions. Possibly some new files may be added to the product, or some may be removed. The product version is not changed when a new patch is installed in it. However, it is possible to find out which patches are installed in a product version.

Patches are identified by their names. Names can be defined simply by a patch name and sequential numbers. The sequence number never starts over. A patch is however uniquely related to a product version. If the same problem must be fixed in form of a patch in two product versions, two patches must be generated.

Whenever possible, patches should be avoided. It is much more accurate to send a product revision and have full control over distributed software.

Patch names should include the product name and the patch number. For example SDE-P012.

Patches within the development environment (called internal patches) are managed in a slightly different way than patches for the final product. The development environment covers a network, including different types of servers, like release servers, and include several versions of the same product. For this reason, internal patches require addition support.

9.1 Managing Patches in the Development Environment

The file versions modified for the patch must be marked in order to have a possibility to re-create patches. The SDE command

rcsname patch_name file file ...

can be used for it. The patch_name should include product version name and patch number.

A patch may be built from the latest versions of source files, as a part of further improvement. In that case the latest version of files should be checked out and after the modification checked in as the latest versions

Fig 9.1 The latest version of a file is used for a patch

It may however happen that a patch must be made on an old file version. Later versions may contain some new functions which are not part of the delivered release. In that case, a parallel branch, starting from the released version must be created.

Fig 9.2 An old file version must be changed due to a patch

Note that it is not necessary to create a new system configuration for a new patch. If the product release is created from the current system configuration, the patch file versions can be created in the current system configuration. In that case it is sufficient to create patch file versions as latest versions or as branches as specified above.

If a patch has to be made for a product version created from an old system configuration, then patch file versions must be placed in the old configuration. There are two possibilities to manage patches on an old configuration, which depends on how much re-building is required for the patches.

If it is too costly (time and disc space) to rebuild the entire system configuration, the patches can be built directly in the old system configuration. The old system configuration must be unfrozen, so that file scan be checked out and in. The file patch versions must be created as branches. When the system is rebuilt, the configuration includes the changes of the patch. After the patch is delivered, the system configuration may be frozen again.

If several patches have to be fixed at the same time, and if the entire system has to be rebuilt anyway, it is a good idea to create a new system configuration, a patch configuration, from the old configuration. It is not necessary to create new RCS libraries, only the configuration containing RCS links to the old configuration may be created. The RCS libraries in the old configuration must be unfrozen. The patches are created in the patch configuration. The patch file versions must be created as branches.

9.2 Patches in the Development Environment

It is essential that every user of a product (component) can see which patches are installed, or present but not installed, in the current and any version of the product.

This section describes how the patches should be installed into a product version, un-installed, and where they can be found.

9.2.1 Patch Directory Structure

A product is defined by its name and version (for example OMF*1.1-0b, OIS*1.1-0, etc.). In the HP-UX system a product (component) is designed as a directory tree. Peaches related to a product version are placed in the patch directory under the product version directory (Figure 9-3).

Fig 9.3 Product directory structure with the patch subdirectory structure

Each patch contains patched files that will replace the corresponding original product files, description files that describe the changes which are included in the patched files and finally a description file that defines how the patches files will be installed into the product.

Every patch is distributed as a directory tree. The top directory name corresponds to the patch name, for example PATCH_nn, where nn is the patch number.

Each patch top directory contains the following files:


bin/file $PRODUCT_ROOT/bin ; chmod 555 $FILE

This line specifies a file placed in the bin subdirectory in the patch and that will be copied to the product bin subdirectory.

  • PATCH_nn_customize - this is an optional korn-shell script which is executed after the patch files are copied to the product. Usually this file is not needed. Only if some additional actions must be done during the install process, this script can be used.
  • PATCH_nn_decustomize - this is also an optional korn-shell script which is executed after the patch is removed from the product version. Only if some additional actions are required, this script must be created.
  • README file - an optional text file that shortly describes the changes the patch contains.
  • If a patch is going to be installed into several product versions or variants, it must be placed in the patch directory under each version (or variant). Often the same patches must be installed in all product variants, but their binary files are different.

    9.2.2 Commands for the Patch Installation into the Product Version

    If the patch directory structure and file contents specified above are followed exactly, then the following commands may be used:

    Figure 9-4 shows an example of a patch that includes three files - file1, file2 and lib3. The figure shows the structure before the patch was installed. Original files are still placed in original subdirectories, and patch files are still placed under the patch directory.

    Fig 9.4 Patch directory structure - before the patinstall execution

    The patinstall command moves the pach files to the places of the original files, while the original files are saved under the patch directory. The command also creates a file called uninstall.dat that describe how the patch can be uninstalled. Figure 9-5 shows the patch and product version structure after the patinstall execution.

    Fig 9.5 Patch directory structure after the patinstall execution

    9.3 Patch Delivery

    A patch should be delivered in the same way as a product version (release). The product responsible project should create the patch, copy it to release node (or to the distribution node) under the product version. If necessary, a tar file can be created containing the patch and send to other projects. Other projects should copy the patch via network, or install it from the tape to their product structure.

    [Top] [Prev] [Next] [Bottom]