Writing a request Script

The request script is the only way your package can interact directly with the administrator installing it. It can be used, for example, to ask the administrator if optional pieces of a package should be installed.

The output of a request script must be a list of environment variables and their values. This list can include any of the parameters you created in the pkginfo file and the CLASSES and BASEDIR parameters. The list can also introduce environment variables that have not been defined elsewhere (although the pkginfo file should always provide default values, when practical). For more information on package environment variables, see "Package Environment Variables".

When your request script assigns values to a environment variable, it must then make those values available to the pkgadd command and other package scripts.

request Script Behaviors

• The request script cannot modify any files. It only interacts with administrators installing the package and creates a list of environment variable assignments based upon that interaction. To enforce this restriction, the request script is executed as the non-privileged user install if that user exists; otherwise it is executed as the non-privileged user nobody. The request script does not have superuser authority.

• The pkgadd command calls the request script with one argument that names the script's response file (the file that stores the administrator's responses).

• The request script is not executed during package removal. However, the environment variables assigned by the script are saved and are available during removal.

Design Rules for request Scripts

• There can be only one request script per package and it must be named request.

• The environment variable assignments should be added to the installation environment for use by the pkgadd command and other packaging scripts by writing them to the response file (known to the script as $1).

• System environment variables and standard installation environment variables, except for the CLASSES and BASEDIR parameters, cannot be modified by a request script. Any of the other environment variables you created can be changed.

A request script can only modify the BASEDIR parameter as of Solaris 2.5 and later releases.

• Every environment variable that the request script may manipulate should be assigned a default value in the pkginfo file.

• The format of the output list should be PARAM=value. For example:

  CLASSES=none class1

• The administrator's terminal is defined as standard input to the request script.

• Do not perform any special analysis of the target system in a request script. It is risky to test the system for the presence of certain binaries or behaviors, and set environment variables based upon that analysis, because there is no guarantee that the request script will actually be executed at install time. The administrator installing the package may provide a response file that will insert the environment variables without ever calling the request script. If the request script is also evaluating the target file system, that evaluation may not happen. An analysis of the target system for special treatment is best left to the checkinstall script.

If it is possible that the administrators who will be installing your package will be using the JumpStart^TM product, then the installation of your package must not be interactive. This implies that either you should not provide a request script with your package, or you need to communicate to the administrator that they should use the pkgask command, prior to installation, to store their responses to the request script. For more information on the pkgask command, see the pkgask(1M) man page.