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 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.
/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 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".
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.
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".
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 "Orga