The term ‘package’ in this document may be taken to mean a related group of ADAM applications. Packages are described as standard if they are installed at every Starlink site or option if the are only installed when requested by users. Allowance is also made for local packages which are non-Starlink packages set up for general use at particular sites. It is assumed that packages may be run directly from the shell or from ICL; where this is not the case, the inappropriate files are omitted from the installation.
In most cases applications in the package will all be linked into a single monolith (see SUN/144) for efficient running from ICL and to save disk space. Packages could however be defined to consist of any mixture of task types and procedures – they could, in fact, include elements from other packages. Because a package may well consist of applications written by a number of different authors, the term Package Administrator is used for the person with overall responsibility for the package.
Executable files, shell scripts, ICL command files and compiled interface files associated with a
package will usually be installed in a directory referred to by environment variable package_DIR. For
most applications packages this directory is /star/bin/package. If the package can be run direct from
the shell, package_DIR should also contain links with the name of each application in a monolith
pointing to that monolith.
e.g. % ln $KAPPA_DIR/kappa_pm $KAPPA_DIR/add
Individual interface files will also be required in addition to the monolithic interface file in this case.
Each package should provide a Package Help Library. This is a Starlink HELP library (see SUN/124). The structure of the HELP library is at the Package Administrator’s discretion but at the very least it should contain an overall description of the package with subtopics for each application.
The usual format is described below:
Package Help Libraries will usually be installed in directory /star/help/package and named
package.shl. Environment variable package_HELP should be defined to point to the Package Help
Library and this used in the relevant commands.
Generally, to start up a package for use direct from the shell, the user will type:
% package
The Starlink login procedures will have defined command, package, which, when issued by the user, will cause commands in the Package Startup Script to be obeyed.
The Package Startup Script will define commands for running the individual applications and for obtaining help. It should also issue a ‘Welcome’ message stating the package name and version. Typically it will contain mainly alias commands of the form:
% alias application $package_DIR/application
e.g.:
% alias add $KAPPA_DIR/add
(Note that here $KAPPA_DIR/add is a link to the KAPPA monolith as described in Section 2.1).
The Package Startup Script should be provided by the Package Administrator and be installed in package_DIR.
Generally, to start up a package under ICL, the user will type:
ICL> package
This will cause ICL commands in the Package Definition Command File to be obeyed. All but the simplest packages will contain a Package Definition Command File which is a file containing ICL commands to:
For example, the Package Definition Command File for KAPPA on Unix could be something like:
The Package Definition Command File is controlled by the Package Administrator and should be installed in package_DIR.
For very simple packages, a Package Definition Command File may not be appropriate – the commands required to run such a package may be set up directly by the overall system startup procedures.