Traditional Approach

Relocatable Packages

The System V ABI implies that the original intention behind the relocatable package was to make installing the package more convenient for the administrator. Now the need for relocatable packages goes much further. Convenience is not the only issue, rather it is quite possible that during the installation an active software product is already installed in the default directory. A package that is not designed to deal with this situation either overwrites the existing product or fails to install. However, a package designed handle multiple architectures and multiple versions can install smoothly and offer the administrator a wide range of options that are fully compatible with existing administrative traditions.

In some ways the problem of multiple architectures and the problem of multiple versions is the same. It must be possible to install a variant of the existing package side by side with other variants, and direct clients or standalone consumers of exported file systems to any one of those variants, without degraded functionality. While Sun has established methods for dealing with multiple architectures on a server, the administrator may not adhere to those recommendations. All packages need to be capable of complying with the administrators' reasonable wishes regarding installation.

Example-A Traditional Relocatable Package

This example shows what a traditional relocatable package may look like. The package is to be located in /opt/SUNWstuf, and its pkginfo file and pkgmap file might look like this.

This is referred to as the traditional method because every package object is installed to the base directory defined by the BASEDIR parameter from the pkginfo file. For example, the first object in the pkgmap file is installed as the directory /opt/SUNWstuf.

Absolute Packages

An absolute package is one that installs to a particular root (/) file system. These packages are difficult to deal with from the standpoint of multiple versions and architectures. As a general rule, all packages should be relocatable. There are, however very good reasons to include absolute elements in a relocatable package.

Example-A Traditional Absolute Package

If the SUNWstuf package was an absolute package, the BASEDIR parameter should not be defined in the pkginfo file, and the pkgmap file would look like this.

In this example, if the administrator specified an alternate base directory during installation, it would be ignored by the pkgadd command. This package always installs to /opt/SUNWstuf of the target system.

The -R argument to the pkgadd command works as expected. For example,

pkgadd -d . -R /export/opt/client3 SUNWstuf

installs the objects in /export/opt/client3/opt/SUNWstuf; but that is the closest this package comes to being relocatable.

Notice the use of the question mark (?) for the /opt directory in the pkgmap file. This indicates that the existing attributes should not be changed. It does not mean "create the directory with default attributes," although under certain circumstances that may happen. Any directory that is specific to the new package must specify all attributes explicitly.

Composite Packages

Any package containing relocatable objects is referred to as a relocatable package. This can be misleading because a relocatable package may contain absolute paths in its pkgmap file. Using a root (/) entry in a pkgmap file can enhance the relocatable aspects of the package. Packages that have both relocatable and root entries are called composite packages.

Example-A Traditional Solution

Assume that one object in the SUNWstuf package is a startup script executed at run level 2. The file /etc/rc2.d/S70dostuf needs to be installed as a part of the package, but it cannot be placed into the base directory. Assuming that a relocatable package is the only solution, the pkginfo and a pkgmap might look like this.

There is not much difference between this approach and that of the absolute package. In fact, this would be better off as an absolute package--if the administrator provided an alternate base directory for this package, it would not work!

In fact, only one file in this package needs to be root-relative, the rest could be moved anywhere. How to solve this problem through the use of a composite package is discussed throughout the remainder of this section.