openSolaris 2008 - Soliciting Input From the Administrator - Application Packaging Developer's Guide

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).

Case Study Files

The `pkginfo` File

PKG=ncmp
NAME=NCMP Utilities
CATEGORY=application, tools
BASEDIR=/
ARCH=SPARC
VERSION=RELEASE 1.0, Issue 1.0
CLASSES=""
NCMPBIN=/bin
NCMPMAN=/usr/man
EMACS=/usr/emacs

The `prototype` File

i pkginfo
i request
x bin $NCMPBIN 0755 root other
f bin $NCMPBIN/dired=/usr/ncmp/bin/dired 0755 root other
f bin $NCMPBIN/less=/usr/ncmp/bin/less 0755 root other
f bin $NCMPBIN/ttype=/usr/ncmp/bin/ttype 0755 root other
f emacs $NCMPBIN/emacs=/usr/ncmp/bin/emacs 0755 root other
x emacs $EMACS 0755 root other
f emacs $EMACS/ansii=/usr/ncmp/lib/emacs/macros/ansii 0644 root other
f emacs $EMACS/box=/usr/ncmp/lib/emacs/macros/box 0644 root other
f emacs $EMACS/crypt=/usr/ncmp/lib/emacs/macros/crypt 0644 root other
f emacs $EMACS/draw=/usr/ncmp/lib/emacs/macros/draw 0644 root other
f emacs $EMACS/mail=/usr/ncmp/lib/emacs/macros/mail 0644 root other
f emacs $NCMPMAN/man1/emacs.1=/usr/ncmp/man/man1/emacs.1 0644 root other
d man $NCMPMAN 0755 root other
d man $NCMPMAN/man1 0755 root other
f man $NCMPMAN/man1/dired.1=/usr/ncmp/man/man1/dired.1 0644 root other
f man $NCMPMAN/man1/ttype.1=/usr/ncmp/man/man1/ttype.1 0644 root other
f man $NCMPMAN/man1/less.1=/usr/ncmp/man/man1/less.1 0644 inixmr other

The `request` Script

trap 'exit 3' 15
# determine if and where general executables should be placed
ans=`ckyorn -d y \
-p "Should executables included in this package be installed"
` || exit $?
if [ "$ans" = y ]
then
   CLASSES="$CLASSES bin"
   NCMPBIN=`ckpath -d /usr/ncmp/bin -aoy \
   -p "Where should executables be installed"
   ` || exit $?
fi
# determine if emacs editor should be installed, and if it should
# where should the associated macros be placed
ans=`ckyorn -d y \
-p "Should emacs editor included in this package be installed"
` || exit $?
if [ "$ans" = y ]
then
   CLASSES="$CLASSES emacs"
   EMACS=`ckpath -d /usr/ncmp/lib/emacs -aoy \
   -p "Where should emacs macros be installed"
   ` || exit $?
fi

Note that a request script can exit without leaving any files on the file system. For installations on Solaris versions prior to 2.5 and compatible versions (where no checkinstall script may be used) the request script is the correct place to test the file system in any manner necessary to ensure that the installation will succeed. When the request script exits with code 1, the installation will quit cleanly.

These example files show the use of parametric paths to establish multiple base directories. However, the preferred method involves use of the BASEDIR parameter which is managed and validated by the pkgadd command. Whenever multiple base directories are used, take special care to provide for installation of multiple versions and architectures on the same platform.