Chapter 5

Package Creation Case Studies

This chapter provides case studies to show packaging scenarios such as installing objects conditionally, determining at run time how many files to create, and modifying an existing data file during package installation and removal.

Each case study begins with a description, followed by a list of the packaging techniques used, a narrative description of the approach taken when using those techniques, and sample files and scripts associated with the case study.

This is a list of the case studies in this chapter:

Soliciting Input From the Administrator

The package in this case study has three types of objects. The administrator may choose which of the three types to install and where to locate the objects on the installation machine.

Techniques

This case study demonstrates the following techniques:

Using parametric path names (variables in object path names) that are used to establish multiple base directories

For information on parametric path names, see "Parametric Path Names".
Using a request script to solicit input from the administrator

For information on request scripts, see "Writing a request Script".
Setting conditional values for an installation parameter

Approach

To set up the selective installation in this case study, you must complete the following tasks:

Define a class for each type of object that can be installed.

In this case study, the three object types are the package executables, the man pages, and the emacs executables. Each type has its own class: bin, man, and emacs, respectively. Notice that in the prototype file all the object files belong to one of these three classes.
Initialize the CLASSES parameter in the pkginfo file to null.

Normally when you define a class, you should list that class in the CLASSES parameter in the pkginfo file. Otherwise, no objects in that class are installed. For this case study, the parameter is initially set to null, which means no objects will get installed. The CLASSES parameter will be changed by the request script, based on the choices of the administrator. This way, the CLASSES parameter is set to only those object types that the administrator wants installed.

Note - Usually it is a good idea to set parameters to a default value. If this package had components common to all three object types, you could assign them to the none class, and then set the CLASSES parameter equal to none.
Insert parametric path names into the prototype file.

The request script sets these environment variables to the value that the administrator provides. Then, the pkgadd command resolves these environment variables at installation time and knows where to install the package.

The three environment variables used in this example are set to their default in the pkginfo file and serve the following purposes:
- $NCMPBIN defines the location for object executables
- $NCMPMAN defines the location for man pages
- $EMACS defines the location for emacs executables
The example prototype file shows how to define the object path names with variables.
Create a request script to ask the administrator which parts of the package should be installed and where they should be placed.

The request script for this package asks the administrator two questions:
- Should this part of the package be installed?
  
  When the answer is yes, the appropriate class name is added to the CLASSES parameter. For example, when the administrator chooses to install the man pages associated with this package, the class man is added to the CLASSES parameter.
- If so, where should this part of the package be placed?
  
  The appropriate environment variable is set to the response to this question. In the man page example, the variable $NCMPMAN is set to the response value.
These two questions are repeated for each of the three object types.

At the end of the request script, the parameters are made available to the installation environment for the pkgadd command and any other packaging scripts. The request script does this by writing these definitions to the file provided by the calling utility. For this case study, no other scripts are provided.

When looking at the request script for this case study, notice that the questions are generated by the data validation tools ckyorn and ckpath. For more information on these tools, see ckyorn(1) and ckpath(1).


	Chapter 5 Package Creation Case Studies This chapter provides case studies to show packaging scenarios such as installing objects conditionally, determining at run time how many files to create, and modifying an existing data file during package installation and removal. Each case study begins with a description, followed by a list of the packaging techniques used, a narrative description of the approach taken when using those techniques, and sample files and scripts associated with the case study. This is a list of the case studies in this chapter: "Soliciting Input From the Administrator" "Creating a File at Installation and Saving It During Removal" "Defining Package Compatibilities and Dependencies" "Modifying a File Using Standard Classes and Class Action Scripts" "Modifying a File Using the `sed` Class and a `postinstall` Script" "Modifying a File Using The `build` Class" "Modifying `crontab` Files During Installation" "Installing and Removing a Driver With Procedure Scripts" "Installing a Driver Using the `sed` Class and Procedure Scripts" Soliciting Input From the Administrator The package in this case study has three types of objects. The administrator may choose which of the three types to install and where to locate the objects on the installation machine. Techniques This case study demonstrates the following techniques: Using parametric path names (variables in object path names) that are used to establish multiple base directories For information on parametric path names, see "Parametric Path Names". Using a `request` script to solicit input from the administrator For information on `request` scripts, see "Writing a `request` Script". Setting conditional values for an installation parameter Approach To set up the selective installation in this case study, you must complete the following tasks: Define a class for each type of object that can be installed. In this case study, the three object types are the package executables, the man pages, and the `emacs` executables. Each type has its own class: `bin`, `man`, and `emacs`, respectively. Notice that in the `prototype` file all the object files belong to one of these three classes. Initialize the `CLASSES` parameter in the `pkginfo` file to null. Normally when you define a class, you should list that class in the `CLASSES` parameter in the `pkginfo` file. Otherwise, no objects in that class are installed. For this case study, the parameter is initially set to null, which means no objects will get installed. The `CLASSES` parameter will be changed by the `request` script, based on the choices of the administrator. This way, the `CLASSES` parameter is set to only those object types that the administrator wants installed. Note - Usually it is a good idea to set parameters to a default value. If this package had components common to all three object types, you could assign them to the `none` class, and then set the `CLASSES` parameter equal to `none`. Insert parametric path names into the `prototype` file. The `request` script sets these environment variables to the value that the administrator provides. Then, the `pkgadd` command resolves these environment variables at installation time and knows where to install the package. The three environment variables used in this example are set to their default in the `pkginfo` file and serve the following purposes: `$NCMPBIN` defines the location for object executables `$NCMPMAN` defines the location for man pages `$EMACS` defines the location for `emacs` executables The example `prototype` file shows how to define the object path names with variables. Create a `request` script to ask the administrator which parts of the package should be installed and where they should be placed. The `request` script for this package asks the administrator two questions: Should this part of the package be installed? When the answer is yes, the appropriate class name is added to the `CLASSES` parameter. For example, when the administrator chooses to install the man pages associated with this package, the class `man` is added to the `CLASSES` parameter. If so, where should this part of the package be placed? The appropriate environment variable is set to the response to this question. In the man page example, the variable `$NCMPMAN` is set to the response value. These two questions are repeated for each of the three object types. At the end of the `request` script, the parameters are made available to the installation environment for the `pkgadd` command and any other packaging scripts. The `request` script does this by writing these definitions to the file provided by the calling utility. For this case study, no other scripts are provided. When looking at the `request` script for this case study, notice that the questions are generated by the data validation tools `ckyorn` and `ckpath`. For more information on these tools, see `ckyorn`(1) and `ckpath`(1).