Procedure Script Behaviors
Procedure scripts are executed as uid=root and gid=other.
Design Rules for Procedure Scripts
Each script should be able to be executed more than once since it is executed once for each volume in a package. This means that executing a script any number of times with the same input produces the same results as executing the script only once.
Each procedure script that installs a package object not in the pkgmap file must use the installf command to notify the package database that it is adding or modifying a path name. After all additions or modifications are complete, this command should be invoked with the -f option. Only postinstall and postremove scripts may install package objects in this way. See installf(1M) and Chapter 5, Package Creation Case Studies for more information.
Administrator interaction is not permitted during execution of a procedure script. All administrator interaction is restricted to the request script.
Each procedure script that removes files not installed from the pkgmap file must use the removef command to notify the package database that it is removing a path name. After removal is complete, this command should be invoked with the -f option. See removef(1M) and Chapter 5, Package Creation Case Studies for details and examples.
Note - The installf and removef commands must be used because procedure scripts are not automatically associated with any path names listed in the pkgmap file.
How to Write Procedure Scripts
Make the directory containing your information files the current working directory.
Create one or more procedure scripts with your favorite text editor.
A procedure script must be named one of the predefined names: preinstall, postinstall, preremove, or postremove.
Save your changes and quit the editor.
Complete one of the following tasks.
If you want to create class action scripts, skip to the next task, "How to Write Class Action Scripts".
If you have not created your prototype file, complete the procedure "How to Create a prototype File Using the pkgproto Command", and skip to Step 5.
If you have already created your prototype file, edit it and add an entry for each installation script you just created.
Build your package.
See "How to Build a Package", if needed.
Where to Go Next
After you build the package, install it to confirm that it installs correctly and verify its integrity. Chapter 4, Verifying and Transferring a Package explains how to do this and provides step-by-step instructions on how to transfer your verified package to a distribution medium.
Writing Class Action Scripts
Defining Object Classes
Object classes allow a series of actions to be performed on a group of package objects at installation or removal. You assign objects to a class in the prototype file. All package objects must be given a class, although the class of none is used by default for objects that require no special action.
The installation parameter CLASSES, defined in the pkginfo file, is a list of classes to be installed (including the none class).
Note - Objects defined in the pkgmap file that belong to a class not listed in this parameter in the pkginfo file will not be installed.
The CLASSES list determines the order of installation. Class none is always installed first, if present, and removed last. Since directories are the fundamental support structure for all other file system objects, they should all be assigned to the none class. Exceptions can be made, but as a general rule, the none class is safest. The reason for this is to ensure that the directories are created before the objects they will contain and also to ensure that no attempt is made to delete a directory before it has been emptied.
How Classes Are Processed During Installation
The following list describes the system actions that occur when a class is installed. The actions are repeated once for each volume of a package as that volume is being installed.
The pkgadd command creates a path name list.
The pkgadd command creates a list of path names upon which the action script will operate. Each line of this list contains source and destination path names, separated by a space. The source path name indicates where the object to be installed resides on the installation volume and the destination path name indicates the location on the target system where the object should be installed. The contents of the list are restricted by the following criteria:
The list contains only path names belonging to the associated class.
If the attempt to create the package object fails, directories, named pipes, character devices, block devices, and symbolic links are included in the list with the source path name set to /dev/null. Normally they will be automatically created by the pkgadd command (if not already in existence) and given proper attributes (mode, owner, group) as defined in the pkgmap file.
Linked files where the file type is l are not included in the list under any circumstances. Hard links in the given class are created in item 4.
If no class action script is provided for installation of a particular class, the path names in the generated list are copied from the volume to the appropriate target location.
If there is a class action script, the script is executed.
The class action script is invoked with standard input containing the list generated in item 1. If this is the last volume of the package, or there are no more objects in this class, the script is executed with the single argument of ENDOFCLASS.
Note - Even if there are no regular files of this class anywhere in the package, the class action script will be called at least once with an empty list and the ENDOFCLASS argument.
The pkgadd command performs a content and attribute audit and creates hard links.
After successfully executing items 2 or 3, the pkgadd command audits both content and attribute information for the list of path names. The pkgadd command creates the links associated with the class automatically. Detected attribute inconsistencies are corrected for all path names in the generated list.
How Classes Are Processed During Removal
Objects are removed class by class. Classes that exist for a package but that are not listed in the CLASSES parameter are removed first (for example, an object installed with the installf command). Classes listed in the CLASSES parameter are removed in reverse order. The none class is always removed last. The following list describes the system actions that occur when a class is removed:
The pkgrm command creates a path name list.
The pkgrm command creates a list of installed path names that belong to the indicated class. Path names referenced by another package are excluded from the list unless their file type is e (meaning the file should be edited upon installation or removal).
If the package being removed modified any files of type e during installation, it should remove just the lines it added. Do not delete a non-empty editable file; just remove the lines the package added.
If there is no class action script, the path names are deleted.
If your package has no removal class action script for the class, all the path names in the list generated by the pkgrm command are deleted.
Note - Files with a file type of e (editable), which are not assigned to a class and an associated class action script, will be removed at this point, even if the path name is shared with other packages.
If there is a class action script, the script is executed.
The pkgrm command invokes the class action script with standard input for the script containing the list generated in item 1.
The pkgrm command performs an audit.
After successfully executing the class action script, the pkgrm command removes knowledge of the path names from the package database unless a path name is referenced by another package.