UNIX/IRAF Site Manager's Guide

3.6. Installing and maintaining layered software

The procedures for installing layered software products are similar to those used to install the core IRAF system, or update a package. Layered software may be distributed in source only form, or with binaries; it may be configured for a single architecture, or may be preconfigured to support multiple architectures. The exact procedures to be followed to install a layered product will in general be product dependent, and should be documented in the installation guide for the product.

In brief, the procedure to be followed should resemble the following:

Create the root directory for the new software, somewhere outside the IRAF directories.
Restore the files to disk from a tape or network archive distribution file.
Edit the core system file hlib$extern.pkg to "install" the new package in IRAF. This file is the sole link between the IRAF core system and the external package.
Configure the package BIN directory or directories, either by restoring the BIN to disk from an archive file, or by recompiling and relinking the package with mkpkg.

As always, there are some little things to watch out for. When using mkpkg on a layered product, you must give the name of the system being operated upon, e.g.,

cl> mkpkg -p foo update

where foo is the system or package name, e.g., "noao", "local", etc. The -p flag can be omitted by defining PKGENV in your UNIX environment, but this only works for updates to a single package.

An external system of packages may be configured for multiple architecture support by repeating what was done for the core system. One sets up several BIN directories, one for each architecture, named \f(CWbin.arch, where arch is "sparc", "ddec", "rs6000", etc. These directories, or symbolic links to the actual directories, go into the root directory of the external system. A symbolic link bin pointing to an empty directory bin.generic, and the directory itself, are added to the system's root directory. The system is then stripped of its binaries with rmbin, if it is not already a source only system. Examine the file zzsetenv.def in the layered package LIB directory to verify that the definition for the system BIN (which may be called anything) includes the string "(arch)", e.g.,

set noaobin = "noao$bin(arch)/"

The binaries for each architecture may then be generated by configuring the system for the desired architecture and running mkpkg to update the binaries, for example,

cl> cd foo
cl> mkpkg sparc
cl> mkpkg -p foo update >& spool &

where foo is the name of the system being updated. If any questions arise, examination of a working example of a system configured for multiple architecture support (e.g., the NOAO packages) may reveal the answers.

Once installed and configured, a layered product may be deinstalled merely by archiving the package directory tree, deleting the files, and commenting out the affected lines of hlib$extern.pkg. With the BINs already configured reinstallation is a simple matter of restoring the files to disk and editing the extern.pkg file.