Previous Contents Index Next |
Setup Util Programmer's Guide |
Chapter 10 Dependencies and Patches
This chapter explains how to work with dependencies and patch software. It contains the following sections:
Selecting Interdependent Components
Selecting Interdependent Components
Server components often rely on each other. Unfortunately, writing code to manage these dependencies is not always easy, especially in situations where some components require upgrades and others do not. The Setup Util fixes this problem by supporting dependency rules within information files.
Searching for Components
After a user specifies an installation directory, the Common Install Shell reads all component names in the master information file and any listed package information files. Additionally, if the installation directory exists, the Shell reads all information files from it. This establishes a list of available components.
Checking Dependencies
At this point, the Common Install Shell begins checking if any components specified by a dependencies directive are installed. If a component is installed, the Shell checks its version. If a listed component is older than an installed one, it is removed from the available components list.
Presenting a Selection List
Once the Common Install Shell finishes checking dependencies, the user is prompted to select one or more components. If the user selects a component for which a dependencies directive exists, all components listed as values of that directive are selected as well. The following examples illustrate this.
Simple Example
The master information file specifies admin and slapd as the components to install. In the admin package information file, slapd is listed as a dependency. In the slapd package information file, admin is listed as a dependency. Choosing either component will select both.
Complex Example
The master information file specifies admin and slapd as the components to install. Both components have a number of interdependent subcomponents. The admin package information file lists the following subcomponents:
The slapd package information file lists these subcomponents:
The result of selecting each different subcomponent from within the Common Install Shell is summarized in Table 3-1.
Table 10-1 The results of selecting different components.
Determining Installation Order
Once the user has selected the components to install, the Common Install Shell determines the order in which to install them. The order is based on product dependencies and information file directives.
If there are no dependencies, components are installed in the same order as they are listed in the information files. The Install Shell runs each component's pre-installation and post-installation program before proceeding to the next component.
If there are dependencies, the low-level components (those that other components depend on) are installed first, followed by the high-level components (those that are dependent). If two components are at the same level but are not dependent on each other, the Install Shell orders them according to the following hard-coded internal list:
svrcore, base, slapd, admin, cert, msg, mail, news, calendar, proxy, https, httpd, compass
Invisible Components
In some circumstances you may not want the Common Install Shell to list a component, even if it is selected. If a component is mandatory or never installed on its own, it may be preferable to select it in the background without showing the user. You can do this by flagging a component as invisible.
Set the component's Visible directive to False. Depending on different combinations of the Mandatory, Checked, and Dependencies directives, an invisible component may or may not be installed. The results of these various combinations are summarized in Table 3-3.
Table 10-2 Different directive combinations determine whether an invisible component is installed.
Installing Patches
The Setup Util supports patch installation for any product that was initially set up by the Common Install Shell. You can use patches to apply fixes and partial upgrades to these products.
Performing a Patch
Patching a product is, in some ways, the same as installing a new product. You must create a product archive, write a package information file, and use the Common Install Shell. You can also write pre- and post-installation programs.
There are, however, a few differences between patches and full installations. When writing a package information file for a patch, you must specify several additional directives. These are Type, ApplyTo, and PatchID. Table 10-2 summarizes all directives that you can use when performing a patch.
Table 10-3 You can use the following directives in package information files for patches.
Set value to Patch to indicate that this is a patch installation.
Specifies the product and version to patch. Use the syntax ApplyTo=Product/Version.
Unique name used to identify the patch. For example, PatchID=quickfix1.
Used to create log and backup files. Do not use special characters or spaces in the nickname. If this directive is not specified, the Common Install Shell will use the value of the PatchID directive.
Pre-uninstallation program for the patch. See Chapter 11 "Uninstalling," for more information about uninstallation.
Post-uninstallation program for the patch. See Chapter 11 "Uninstalling," for more information about uninstallation.
Specifies the security level of the patch. Possible values are domestic, export, and none
The Common Install Shell will change the product's version number to the numeric value specified here.
When you patch a file, you are overwriting an old version with a new one. You can patch multiple files by including all of them in your archive. Before overwriting a file, the Common Install Shell backs it up for use during uninstallation. It then installs the new file and writes information to a file in the <server root>/setup directory called <product_name>-patch.inf.
Previous Contents Index Next
Copyright (C) 2005 Red Hat, Inc. All rights reserved.
This material may be distributed only subject to the terms and conditions set forth in the Open Publication License, v1.0 or later (the latest version is presently available at http://www.opencontent.org/openpub/
Last Updated September 21, 2001