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).
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. This strategy ensures that the directories are created before the objects they will contain. In addition, no attempt is made to delete a directory before it has been emptied.
The pkgadd command creates a list of path names upon which the action script operates. 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. 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 that belong to the associated class.
If the attempt to create the package object fails, then 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, these items are 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.
A class action script is executed if one exists.
The class action script is invoked with standard input that contains the list generated in item 1. If this volume is the last volume of the package, or no more objects exist in this class, the script is executed with the single argument of ENDOFCLASS.
Even if no regular files of this class exist in the package, the class action script is 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.
Objects are removed class by class. Classes that exist for a package but 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 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. A file type of e means the file should be edited upon installation or removal.
If the package being removed had modified any files of type e during installation, it should remove just the lines it added. Do not delete a non-empty editable file. Remove the lines that the package added.
If no class action script exists, 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.
Files with a file type of e (editable) are not assigned to a class and an associated class action script. These files are removed at this point, even if the path name is shared with other packages.
If a class action script exists, the script is executed.
The pkgrm command invokes the class action script with standard input for the script that contains the list generated in item 1.
The pkgrm command performs an audit.
After successfully executing the class action script, the pkgrm command removes references to the path names from the package database unless a path name is referenced by another package.
The class action script defines a set of actions to be executed during installation or removal of a package. The actions are performed on a group of path names based on their class definition. See Chapter 5, Case Studies of Package Creation for examples of class action scripts.
The name of a class action script is based on the class on which it should operate and whether those operations should occur during package installation or package removal. The two name formats are shown in the following table:
Operates on path names in the indicated class during package installation
Operates on path names in the indicated class during package removal
This file name format is not used for files that belong to the sed, awk, or build system classes. For more information on these special classes, see The Special System Classes.
A script is executed for all files in the given class on the current volume.
The pkgadd and pkgrm commands create a list of all objects listed in the pkgmap file that belong to the class. As a result, a class action script can act only upon path names defined in the pkgmap that belong to a particular class.
When a class action script is executed for the last time (that is, no more files belong to that class), the class action script is executed once with the keyword argument ENDOFCLASS.
Administrator interaction is not permitted during execution of a class action script.
If a package spans more than one volume, the class action script is executed once for each volume that contains at least one file that belongs to a class. Consequently, each script must be able to be executed more than once. This means that executing a script any number of times with the same input must produce the same results as executing the script only once.
When a file is part of a class that has a class action script, the script must install the file. The pkgadd command does not install files for which a class action script exists, although it does verify the installation.
A class action script should never add, remove, or modify a path name or system attribute that does not appear in the list generated by the pkgadd command. For more information on this list, see item 1 in How Classes Are Processed During Package Installation.
When your script sees the ENDOFCLASS argument, put post-processing actions such as clean up into your script.
All administrator interaction is restricted to the request script. Do not try to obtain information from the administrator by using a class action script.
Provides a method for using sed instructions to edit files upon package installation and removal.
Provides a method for using awk instructions to edit files upon package installation and removal.
Provides a method to dynamically construct or modify a file by using Bourne shell commands.
Provides a method to preserve files that should not be overwritten by future package installations.
Provides automated installation and uninstallation of SMF (Service Management Facility) services associated with a manifest. The manifest class should be used for all SMF manifests in a package.
If several files in a package require special processing that can be fully defined through sed, awk, or sh commands, installation is faster by using the system classes rather than multiple classes and their corresponding class action scripts.
The sed class provides a method to modify an existing object on the target system. The sed class action script executes automatically at installation if a file that belongs to class sed exists. The name of the sed class action script should be the same as the name of the file on which the instructions are executed.
A sed class action script delivers sed instructions in the following format:
Two commands indicate when instructions should be executed. The sed instructions that follow the !install command are executed during package installation. The sed instructions that follow the !remove command are executed during package removal. The order in which these commands are used in the file does not matter.
The awk class action script is executed automatically at installation if a file that belongs to class awk exists. Such a file contains instructions for the awk class script in the following format:
Two commands indicate when instructions should be executed. The awk instructions that follow the !install command are executed during package installation. The instructions that follow the !remove command are executed during package removal. These commands may be used in any order.
The name of the awk class action script should be the same as the name of the file on which the instructions are executed.
The file to be modified is used as input to the awk command and the output of the script ultimately replaces the original object. Environment variables may not be passed to the awk command with this syntax.
For more information on awk instructions, see the awk(1) man page.
The build class creates or modifies a package object file by executing Bourne shell instructions. These instructions are delivered as the package object. The instructions run automatically at installation if the package object belongs to the build class.
The name of the build class action script should be the same as the name of the file on which the instructions are executed. The name must also be executable by the sh command. The script's output becomes the new version of the file as it is built or modified. If the script produces no output, the file is not created or modified. Therefore, the script can modify or create the file itself.
For example, if a package delivers a default file, /etc/randomtable, and if the file does not already exist on the target system, the prototype file entry might be as follows:
e build /etc/randomtable ? ? ?
The package object, /etc/randomtable, might look like the following:
!install # randomtable builder if [ -f $PKG_INSTALL_ROOT/etc/randomtable ]; then echo "/etc/randomtable is already in place."; else echo "# /etc/randomtable" > $PKG_INSTALL_ROOT/etc/randomtable echo "1121554 # first random number" >> $PKG_INSTALL_ROOT/etc/randomtable fi !remove # randomtable deconstructor if [ -f $PKG_INSTALL_ROOT/etc/randomtable ]; then # the file can be removed if it's unchanged if [ egrep "first random number" $PKG_INSTALL_ROOT/etc/randomtable ]; then rm $PKG_INSTALL_ROOT/etc/randomtable; fi fi
See Chapter 5, Case Studies of Package Creation for another example using the build class.
The preserve class preserves a package object file by determining whether or not an existing file should be overwritten when the package is installed. Two possible scenarios when using a preserve class script are:
If the file to be installed does not already exist in the target directory, the file will be installed normally.
If the file to be installed exists in the target directory, a message describing that the file exists is displayed, and the file is not installed.
Both scenario outcomes are considered successful by the preserve script. A failure occurs only in the second scenario when the file is unable to be copied to the target directory.
Starting with the Solaris 7 release, the i.preserve script and a copy of this script, i.CONFIG.prsv, can be found in the /usr/sadm/install/scripts directory with the other class action scripts.
Modify the script to include the filename or filenames you would like to preserve.
The manifest class automatically installs and uninstalls SMF (Service Management Facility) services associated with an SMF manifest. If you are not familiar with SMF, see Chapter 17, Managing Services (Overview), in System Administration Guide: Basic Administration for information about how to use SMF to manage services.
All service manifests within packages should be identified with the class manifest. Class action scripts that install and remove service manifests are included in the packaging subsystem. When pkgadd(1M) is invoked, the service manifest is imported. When pkgrm(1M) is invoked, instances in the service manifest that are disabled are deleted. Any services in the manifest that have no remaining instances are also deleted. If the -R option is supplied to pkgadd(1M) or pkgrm(1M), these service manifest actions will be done when the system is next rebooted with that alternate root path.
The following portion of code from a package information file shows the use of the manifest class.
# packaging files i pkginfo i copyright i depend i preinstall i postinstall i i.manifest i r.manifest # # source locations relative to the prototype file # d none var 0755 root sys d none var/svc 0755 root sys d none var/svc/manifest 0755 root sys d none var/svc/manifest/network 0755 root sys d none var/svc/manifest/network/rpc 0755 root sys f manifest var/svc/manifest/network/rpc/smserver.xml 0444 root sys