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 does not need an absolute path location on the target system. Instead, the object's location is determined during the installation process.

All or some of a package's objects can be defined as relocatable. Before writing any installation scripts or creating the prototype file, decide if package objects will have fixed locations (such as start-up scripts in /etc) or be relocatable .

There are two kinds of relocatable objects, collectively relocatable and individually relocatable.

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:

BASEDIR=/opt

This example means that when the object is installed, it will be located in the /opt/tests/generic directory.

The /opt directory is the only directory to which software that is not part of the base Solaris software 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 files in /etc or /var) specified as absolute. However, if a package contains many different relocations, consider dividing the package into multiple packages with distinct BASEDIR values in their pkginfo files.

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. After specifying the install variable, 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. Use of individually relocatable objects might result in widely scattered package components that are difficult to isolate when installing multiple versions or architectures of the package. 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 script or a checkinstall script.

A variable specification in a path must begin or end the path name, or be bounded by slashes (/). Valid parametric path names take the following form:

$PARAM/tests
tests/$PARAM/generic
/tests/$PARAM

The variable specification, once defined, may cause the path to be evaluated as absolute or relocatable. In the following example, the prototype file contains this entry:

f none $DIRLOC/tests/generic

The pkginfo file contains this entry:

DIRLOC=/myopt

The path name $DIRLOC/tests/generic evaluates to the absolute path name /myopt/tests/generic, regardless of whether the BASEDIR parameter is set in the pkginfo file.

In this example, the prototype file is identical to the one in the previous example and the pkginfo file contains the following entries:

DIRLOC=firstcut
BASEDIR=/opt

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 field in the prototype file defines where the object will be located on the target system. Specify the present location of the package's objects in the prototype file if their directory structure does not mimic the intended structure on the target system. See Organizing a Package's Contents for more information on structuring objects in a package.

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. In this format, path1 is the location the object should have on the target system, and path2 is the location the object has on your system.

You can also use the path1=path2 path name format with path1 as a relocatable object name and path2 as a full path name to that object on your system.

path1 may not contain undefined build variables, but may contain undefined install variables. path2 may not contain any undefined variables, although both build variables and install variables may be used. For information on the difference between install variables and build variables, see Package Environment Variables.

Links must use the path1= path2 format because 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.