Define additional objects to be created at install time.
Create links at install time.
Distribute packages over multiple volumes.
Nest prototype files.
Set a default value for the mode, owner, and group fields.
Provide a search path for the pkgmk command.
Set environment variables.
See the following sections for information on making these changes.
You can use the prototype file to define objects that are not actually delivered on the installation medium. During installation, using the pkgadd command, these objects are created with the required file types, if they do not already exist at the time of installation.
To specify that an object be created on the target system, add an entry for it in the prototype file with the appropriate file type.
For example, if you want a directory created on the target system, but do not want to deliver it on the installation medium, make the following entry for the directory in the prototype file:
d none /directory 0644 root other
If you want to create an empty file on the target system, an entry for the file in the prototype file might look like:
f none filename=/dev/null 0644 bin bin
The only objects that must be delivered on the installation medium are regular files and edit scripts (file types e, v, f) and the directories required to contain them. Any additional objects are created without reference to the delivered objects, directories, named pipes, devices, hard links, and symbolic links.
Its file type as l (a link) or s (a symbolic link).
Its path name with the format path1=path2 where path1 is the destination and path2 is the source file. As a general rule, path2 of a link should never be absolute, but should instead be relative to the directory portion of path1. For example, a prototype file entry defining a symbolic link could be:
s none etc/mount=../usr/etc/mount
Relative links would be specified in this manner whether the package is installed as absolute or relocatable.
However, you can use the optional part field in the prototype file to define in which part you want an object to be located. A number in this field overrides the pkgmk command and forces the placement of the component into the part given in the field. Note that there is a one-to-one correspondence between parts and volumes for removable media formatted as file systems. If the volumes are preassigned by the developer, the pkgmk command will issue an error if there is insufficient space on any volume.
In the following example there are three prototype files, the main one (prototype) being edited, and the two (proto2 and proto3) that are being included.
!include /source-dir/proto2 !include /source-dir/proto3
!default 0644 root other
This command's range starts from where it is inserted and extends to the end of the file, but does not span to included files.
However, for directories (file type d) and editable files (file type e) that you know exist on target systems (like /usr or /etc/vfstab), make sure that the mode, owner, and group fields in the prototype file are set to question marks (?). That way you will not destroy existing settings that a site administrator may have modified.
If the source location for package objects is different than their destination location, and you do not want to use the path1=path2 format as described in A Brief Word on an Object's Source and Destination Locations, then you can use the !search command in the prototype file. For example, if you created a directory, pkgfiles, in your home directory, and it contains all of your information files and installation scripts, you can specify that that directory be searched when the package is built with the pkgmk command.
The command in the prototype file would look like:
Search requests do not span to included files. In addition, a search is limited to the specific directories listed, and will not search recursively.
You can also add commands to the prototype file of the form !PARAM=value. Commands of this form define variables in the current environment. If you have multiple prototype files, the scope of this command is local to the prototype file where it is defined.
The variable PARAM can begin with either a lowercase or uppercase letter, but its value must be known at build time, or the pkgmk command will abort with an error. For more information on the difference between build and install variables, see Package Environment Variables.