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

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:

[admin-server]

dependencies=slapd-server

[admin-client]

dependencies=base-client

[admin-plugin]

dependencies=admin-server

The slapd package information file lists these subcomponents:

[slapd-server]

dependencies=admin-server

[slapd-plugin]

dependencies=slapd-server

[slapd-client]

dependencies=admin-client

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.

Choosing this component...

Selects these components

admin-server  

slapd-server, admin-server  

admin-client  

base-client, admin-client  

admin-plugin  

slapd-server, admin-server, admin-plugin  

slapd-server  

admin-server, slapd-server  

slapd-plugin  

admin-server, slapd-server, slapd-plugin  

slapd-client  

base-client, admin-client, slapd-client  


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.


To Make a Component 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.

Visible

Mandatory

Checked

Dependency

Parent Selection

Result

False  

True  

(Unspecified)  

(Unspecified)  

True  

Installed  

False  

True  

(Unspecified)  

(Unspecified)  

False  

Installed  

False  

False  

True  

False  

True  

Installed  

False  

False  

False  

False  

(Unspecified)  

Not Installed  

False  

False  

False  

True  

(Unspecified)  

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.

Directive

Required

Description

Type  

Yes  

Set value to Patch to indicate that this is a patch installation.  

ApplyTo  

Yes  

Specifies the product and version to patch. Use the syntax ApplyTo=Product/Version.  

Archive  

Yes  

The ZIP file containing the patch.  

PatchID  

Yes  

Unique name used to identify the patch. For example, PatchID=quickfix1.  

Buildnumber  

No  

Build number of the patch.  

Nickname  

No  

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.  

PreInstall  

No  

Pre-installation program for the patch.  

PostInstall  

No  

Post-installation program for the patch.  

PreUninstall  

No  

Pre-uninstallation program for the patch. See Chapter 11 "Uninstalling," for more information about uninstallation.  

PostUninstall  

No  

Post-uninstallation program for the patch. See Chapter 11 "Uninstalling," for more information about uninstallation.  

Security  

No  

Specifies the security level of the patch. Possible values are domestic, export, and none  

Version  

No  

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