12.2 Using GNU tar

For Unix software that does not involve resource forks or creator types, gnutar and gzip can be used to create a .tar.gz or .tgz tarball. This type of tarball preserves paths, permissions, symbolic links, as well as authentication and compression. Tools to uncompress the tarball are available for many platforms.

The automated creation of such a tarball can be worked into the same makefile that is used to build the software. Preservation of resource forks is tricky, but possible, in this method. For example, the following command preserves Macintosh resource forks (where foo/ is a directory):

 $  tar -pczf foo.tgz foo/  

Every good tarball has a single top-level directory that contains everything else. You should not create tarballs that dump their contents into the current directory. To install software packaged this way, use the following command:

 $  tar -pxzf foo.tgz  

This simply unpacks the tarball into the file and directory structure that existed prior to packaging. Basically, it reverses the packing step. This method can be used to write files to the appropriate places on the system, such as /usr/local/bin , /usr/local/lib , /usr/local/man , /usr/local/include , and so on.

When creating packages, you should keep your package contents out of directories such as /etc , /usr/bin , /usr/lib , /usr/include , or any top-level directory reserved for the operating system, since you have no way of knowing what a future software update or Mac OS X upgrade will include. For example, the Fink project stays out of Mac OS X's way by keeping most of its files in /sw . We suggest using /usr/local for the packages that you compile.

This packaging method can also be arranged so that the unpacking is done first in a temporary directory. The user can then run an install script that relocates the package contents to their final destination. This approach is usually preferred, since the install script could be designed to do some basic checking of dependencies, the existence of destination directories, the recataloging of libraries, etc. You could also include an uninstall script with your distribution.

The disadvantages of the tarball method of distributing software are:

• There is no built-in mechanism for keeping track of which files go where.

• There is no built-in method for uninstalling the software.

• It is difficult to list what software is installed and how the installed files depend on each other or on other libraries.

• There is no checking of dependencies and prerequisite software prior to the installation.

These tasks could be built into install and uninstall scripts, but there is no inherently uniform, consistent, and coherent method for accomplishing these tasks when multiple software packages are installed in this manner. Fortunately, more sophisticated methods of packaging, distributing, and maintaining software on Unix systems have been devised, such as Red Hat's RPM, Debian's dpkg , and Apple's PackageMaker.