Where to Go Next
If you are ready to go to the next task, see "How to Create a prototype File Using the pkgproto Command".
Creating a prototype File
The prototype file is an ASCII file used to specify information about the objects in a package. Each entry in the prototype file describes a single object, such as a data file, directory, source file, or executable object. Entries in a prototype file consist of several fields of information separated by white space. Note that the fields must appear in a specific order. Comment lines begin with a pound sign (#) and are ignored.
You can create a prototype file with a text editor or by using the pkgproto command. When you first create this file, it is probably easier to do so with the pkgproto command, because it creates the file based on the directory hierarchy you created previously. If you have not organized your files as described in "Organizing a Package's Contents", you have the cumbersome task of creating the prototype file from scratch with your favorite text editor. However, even when you create the prototype file using the pkgproto command, you will most likely need to make modifications to the file with your favorite text editor, so it is important to understand the format and contents of this file.
The Format of the prototype File
Is an optional, numeric field that enables you to group package objects into parts. The default value is part 1.
Is a one-character field that specifies the object's type. See "The ftype Field".
Is the installation class to which the object belongs. See "The class Field".
Is the absolute or relative path name indicating where the package object will reside on the target system. See "The path Field".
Is the major device number for block or character special devices.
Is the minor device number for block or character special devices.
Is the octal mode of the object (for example, 0644). See "The mode Field".
Is the owner of the object (for example, bin or root). See "The owner Field".
Is the group to which the object belongs (for example, bin or sys). See "The group Field".
Usually, only the ftype, class, path, mode, owner, and group fields are defined, and are described in the following sections. See prototype(4) for additional information on these fields.
The ftype Field
Table 2-3 Valid File Types in the prototype File
Use ftype ...
To Define A ...
Standard executable or data file
File to be edited upon installation or removal (may be shared by several packages)
Volatile file (whose contents are expected to change, like a log file)
Exclusive directory accessible only by this package (may contain unregistered logs or database information)
Character special device
Block special device
Information file or installation script
The class Field
The class field names the class to which an object belongs. Using classes is an optional package design feature, and is discussed in detail in "Writing Class Action Scripts".
If you do not use classes, an object belongs to the none class, and when you execute the pkgmk command to build your package, it will insert the CLASSES=none parameter in the pkginfo file for you. Files with file type i should leave the class field blank.
The path Field
The path field is used to define where the package object will reside on the target system. You may indicate the location with either an absolute path name (for example, /usr/bin/mail) or a relative path name (for example, bin/mail). Using an absolute path name means that the object's location on the target system is defined by the package and cannot be changed. Package objects with relative path names indicate that the object is relocatable.
A relocatable object is one that does not need an absolute path location on the target system. Instead, its location is determined during the installation process.
All or some of a package's objects can be defined as relocatable. You should decide if package objects will have fixed locations (such as start-up scripts in /etc) or be relocatable before you write any installation scripts and before you create the prototype file.
Collectively Relocatable Objects
Collectively relocatable objects are located relative to a common installation base called the base directory. A base directory is defined in the pkginfo file, using the BASEDIR parameter. For example, a relocatable object in the prototype file named tests/generic requires that the pkginfo file define the default BASEDIR parameter. For example:
This means that when the object is installed, it will be located in /opt/tests/generic.
Note - /opt is the only directory to which software that is not part of base Solaris may be delivered.
Use collectively relocatable objects whenever possible. In general, the major part of a package can be relocatable with a few files (such as those in /etc or /var) specified as absolute. However, if a package contains many different relocations, consider dividing your package into multiple packages, each with a different BASEDIR value in its pkginfo file.
Individually Relocatable Objects
Individually relocatable objects are not restricted to the same directory location as collectively relocatable objects. To define an individually relocatable object, you need to specify an install variable in the path field in the prototype file, and then create a request script to prompt the installer for the relocatable base directory, or a checkinstall script to determine the path name from file system data. For more information on request scripts, see "Writing a request Script" and for information on checkinstall scripts, see "How to Gather File System Data".
Note - Individually relocatable objects are difficult to manage and should be avoided. This is because they could result in widely scattered package components that may be difficult to isolate when installing multiple versions or architectures of the package. Try to use collectively relocatable objects whenever possible.
Parametric Path Names
A parametric path name is a path name that includes a variable specification. For example, /opt/$PKGINST/filename is a parametric path name because of the $PKGINST variable specification. A default value for the variable specification must be defined in the pkginfo file. The value may then be changed by a request or checkinstall script.
A variable specification in a path must begin or end the path name, or be bounded by slashes (/). For example, valid parametric path names look like:
$PARAM/tests tests/$PARAM/generic /tests/$PARAM
The variable specification, once defined, may cause the path to be evaluated as absolute or relocatable. For example, given this entry in a prototype file:
f none $DIRLOC/tests/generic
and this entry in the pkginfo file:
the path name, $DIRLOC/tests/generic, will evaluate to the absolute path name /myopt/tests/generic, regardless of whether the BASEDIR parameter is set in the pkginfo file.
However, if the pkginfo file contains these entries
then the path name, $DIRLOC/tests/generic, will evaluate to the relocatable path name /opt/firstcut/tests/generic.
For more information on parametric path names, see "Using Parametric Base Directories".
A Brief Word on an Object's Source and Destination Locations
The path name field in the prototype file defines where the object will be located on the target system. However, if you did not organize your package's objects on your system in a directory structure that mimics their location on the target system (see "Organizing a Package's Contents", then you also need to specify their present location in the prototype file.
If your development area is not structured in the same way that you want your package structured, you can use the path1=path2 format in the path field, where path1 is the location it should have on the target system, and path2 is the location it has on your system.
You can also use the path1=path2 path name format with path1 as a relocatable object name and path2 a full path name to that object on your system.
Note - path1 may not contain undefined build variables, but may contain undefined install variables. path2 may not contain any undefined variables, although both build and install variables may be used. For information on the difference between install and build variables, see "Package Environment Variables".
Links must use the path1= path2 format since they are created by the pkgadd command. As a general rule, path2 of a link should never be absolute, but should instead be relative to the directory portion of path1.
An option to using the path1=path2 format is to use the !search command. For more information, see "Providing a Search Path for the pkgmk Command".
The mode Field
The mode field may contain an octal number, a question mark (?), or a variable specification. An octal number specifies the mode of the object when it is installed on the target system. A ? means that the mode will be unchanged as the object is installed, implying that the object of the same name already exists on the target system.
A variable specification of the form $mode, where the first letter of the variable must be a lowercase letter, means that this field will be set as the package is built. Note that this variable must be defined at build time in either the prototype file or as an option to the pkgmk command. For information on the difference between install and build variables, see "Package Environment Variables".
Files with file type i (information file), l (hard link), and s (symbolic link), should leave this field blank.
The owner Field
The owner field may contain a user name, a question mark (?), or a variable specification. A user name has a maximum of 14 characters and should be a name that already exists on the target system (such as, bin or root). A ? means that the owner will be unchanged as the object is installed, implying that the object of the same name already exists on the target system.
A variable specification can be of the form $Owner or $owner, where the first letter of the variable is either an uppercase letter or a lowercase letter. If the variable begins with a lowercase letter, it must be defined as the package is built, either in the prototype file or as an option to the pkgmk command. If the variable begins with an uppercase letter, the variable specification will be inserted into the pkginfo file as a default value, and may be redefined at install time via a request script. For information on the difference between install and build variables, see "Package Environment Variables".
Files with file type i (information file) and l (hard link) should leave this field blank.