[GAP] Making different versions of GAP available

[John Murdie]

When a new version of a Linux software package like GAP comes along, I
generally make it the default for the users at my site quickly after
some 'local beta' tests, but keep the old version for a few weeks so
that comparison can be made, or so that we can revert to it if
necessary.

This means installing packages under a base directory which is not root
- /, e.g. /opt, so that one would get -
e.g. /opt/gap-20050620/bin, /opt/gap-20050620/lib etc. (If no version
number is provided by the software supplier, we use the ISO format date
of release.) We put links from the contents of the /opt/*/bin
directories to /usr/local/bin (ditto manual pages and documentation).
This allows us to keep multiple versions of a package -
e.g. /opt/gap-20040501, /opt/gap-20050620 - and to choose which should
be considered current. (Anyone wishing to use the older version can
prefix their PATH with the path of its bin directory.)

Alas, this doesn't work with GAP. When one tries to execute one of the
commands - e.g. gnatmake - via a (symbolic or hard) link, one sees:

$ gnatmake main
fatal error, run-time library not installed correctly
cannot locate file system.ads
gnatmake: *** make failed.
$

(I can guess why; it uses $0, the absolute pathname of the invoked
command, to locate the library.)

A solution is to make an - e.g. - /opt/gap-20050620/localbin into which
we put a two-line shell script:

#!/bin/sh
/opt/gap-20050620/bin/`basename $0` $*

linked in all the names of the required executables, and then make links
in /usr/local/bin to each of these (gcc, gdb etc. are not linked, as
they would hide the system's own corresponding commands).

(Another solution, of course, is to set the shell environment variable
which locates the library, but that too requires an interposed shell
script - it is simply not reasonable to ask every user to add the
assignment to this variable in each of their Unix .profiles.)

Switching versions is as easy as giving one command to undo the old
links and another to make the new links - we have a package manager
which does this. (It's not stow(1) -
http://www-128.ibm.com/developerworks/linux/library/l-stow/ - but some
of you may have seen this similar command.)

It would be pleasant if in future the 'localbin' trick were not
necessary with GAP installs.

John A. Murdie
Department of Computer Sciemce