22 August 1995
Jonathan Abbey -- jonabbey@arlut.utexas.edu
With opt_depot, all you need is for your users to have a single directory in their PATH, their LIBPATH, and their MANPATH. With opt_depot, you can easily choose at any time whether you want to have systems on your network use software from a remote NFS server, or installed locally on the system. Packages installed to opt_depot standards can easily be moved anywhere in your filespace and integrated into your users' directories. With opt_depot, you can also easily remove packages that you have installed.
opt_depot was written by staff of the Computer Science Division of the Applied Research Laboratories: The University of Texas at Austin. Primary programmers were Jeremy Thibeaux and Amy Shook, with design assistance from Elaine McSwain and Jonathan Abbey. Later versions have been primarily maintained by Jonathan Abbey.
If you are not using a Central Package Archive, you will not need to run opt_link, and you probably shouldn't need to run opt_setup, either.
There are also special features for selecting which packages and which files have priority over which other packages or files. See the man page for opt_depot for details.
Don't worry if this doesn't all make sense.. hopefully the rest of the document will explain what all this means. You should look at the pictures in doc to get a better feel for what this is all about, as well as the client and server side documentation that we wrote for our local practices.
The Central Package Archive is any location where packages are physically installed for remote access via NFS. These packages are linked into the Local Depot Directory by opt_link for access by opt_depot. The Central Package Archive contains a set of subdirectories, one for each package that you wish to provide access to. Each package should contain a bin directory, a lib directory (if appropriate), include, man, man/manl, etc. Basically each package is a miniature /usr/local to itself.
The file server.gif in the doc directory shows the layout of the Central Package Archive. At our site, the Central Package Archive is called /v/site/packages. /v/site is a generic automounter name for the site volume appropriate for a particular operting system. A SunOS 4.1.3 machine's /v/site would contain packages specifically compiled for SunOS 4.1.3. Ditto for SunOS 5.3 and so forth. All of our site volumes happen to be exported from a single machine, whose physical export points are named /site/SunOS4.1.3, /site/SunOS5.3, and so forth. We use wildcarding in the automounter volume map to make sure that each client accesses the proper site volume.
At ARL:UT we have /v/site/os in addition to /v/site/packages, for software that we want to make available to our NFS clients, but which we want users to have to take affirmative action to make local copies that will be available even if the Central Package Archive server is not available.
The package directory is /v/site/packages in the server.gif diagram. Each package in the Central Package Archive should be configured so that the binary executables and scripts expect to find all of their files in the Local Depot Directory.
Packages in the Central Package Archive can contain .exclude files, which will be integrated into a master .exclude file in the Local Installation Directory. opt_link performs this integration. See here for more info.
The second directory that you will need to specify is the local system's depot directory. This directory will be where all software installed through opt_depot is configured to run from. Each system you want to run client off of opt_depot should have its own copy of this directory.
On our system, this second directory is called /opt/depot. We install our software so that packages look for their files under /opt/depot/<packagename>. For instance, we compile GNU Emacs 19.29 so that it expects to see its files under /opt/depot/emacs-19.29/{bin|lib|include|info} and so forth.
You can see the Local Depot Directory as /opt/depot in doc/client.gif. Notice that the Local Depot Directory can contain software packages that are installed locally in the Local Depot Directory as well as symbolic links to packages installed on the Central Package Archive.
The opt_link script will make symbolic links from your Local Depot Directory to your Central Package Archive. Once this is done, the opt_depot script will make symbolic links in your Local Installation Directory, which is where user's paths (PATH, MANPATH, LD_LIBRARY_PATH) will find the software that you install.
This is the directory that will contain the bin, man, lib, include, and info directories that you want opt_depot to manage. In our case, we have opt_depot managing /opt. opt_depot can work cooperatively with files already existing in /opt/{bin|man| lib|include|info}. opt_depot will cleanly add and remove symbolic links from these directories as appropriate for the packages that you install or remove. The Local Installation Directory need not be in any special place relative to your Local Depot Directory, but the Local Depot Directory must be in the same location across all systems using your packages.
The Local Installation Directory can contain .exclude and .priority files which are used to exclude unwanted pieces of software and to specify how conflicts will be resolved during the opt_depot linking process, respectively.
The man pages, diagrams and documentation that come with the tar file explain things in detail.
The main thing you have to remember is that you must compile and install your software so that it will look for its files through <Local Depot Directory>/<PackageName>. This is what gives the packages position independence, and allows you the choice of installing locally or on a Central Package Archive.
See the client and server side diagrams and instructions for our internal documentation for a more complete diagram of the opt_depot system, which may help resolve some confusion you may have at this point.
Note that by default opt_setup (and all the opt_depot scripts) log to /logs/opt_depot/<directory name>. See the opt_depot and opt_link man pages for details on this logging. The opt_setup script does not set up this logging directory for you, so you need to do that the first time that you get a client system set up for use with opt_depot.
If you look at opt_setup, you'll notice that it is basically perfect for running from a cron job. This is great, just make sure that the opt_depot scripts are run with permission to write to your Local Depot Directory and your Local Installation Directory. Generally, you probably won't want to let average users write in these directories.