| Opt_depot FAQ |
Opt_depot is a suite of perl scripts that several folks here at Applied Research Laboratroies have spent many grueling yet loving hours working on. The result is a tool that makes systems administration tasks involving software installation, de-installation, testing and maintence substantially easier to perform. Once the general workings of opt_depot are understood, the program is simple to run and it creates an enviornment that makes it's own workings invisable to the general user.
The basic idea behind opt_depot has been implemented successfully in many other guises, most notably in Carnagie Mellon's Depot Software.
Software is installed in the form of a package, meaning that the software's component files are placed into sub-directories based on their content -- executables are placed into the package's /bin sub-directory, library routines are placed in /lib, and man page information is placed in /man. There are also /include and /info sub-directories as well. So something like emacs-19.33 would consist of a main directory (e.g. emacs-19.33), under which its own /bin/lin/info/include/man sub-directories would be placed.
To learn more about installing software for use with opt_depot, check out the software installation page.
Make sure that you have a version of perl 5.0 or above installed on your system. Opt_depot 2.0 takes advantage of many perl 5 features, and it won't be able to run with earlier versions of perl.
When installing new software, packages should be compiled so that they expect to find their files under the depot directory (ie "/usr/local", "/opt/depot", etc). That means that if a new version excludes an older one (by listing the old version in a .exclude file), then the old version will not be linked into the depot directory by opt_link and subsequently won't be able to run properly.
So if somone using the network is really infatuated with emacs-19.30, and doesn't like the newer, fancier versions. There is a way to allow this early version to co-exist with other versions in the depot directory, without being designated as the default that is invoked when joe-average user types in "emacs".
The trick here is to allow the older vdersion to be linked into the depot directory, but to exclude all the links to /bin/lib/info/include/man that would normally be built. So if you wanted to have emacs-19.30 able to be accessed through depot, but didn't want it to be the version that everyone uses by default, add the following lines to the .exclude file:
emacs-19.30/bin emacs-19.30/lib emacs-19.30/man emacs-19.30/info emacs-19.30/include
That way, a program like emacs-19.30 can be run by the user who doesn't want to change with the times.
If opt_depot is installed on the network server, then opt_depot's default behavior is to use the 'sites' and configuration files located in the etc/ directory of the opt_depot package itself (i.e. files located on the server). But if a certain client wishes to adopt different variables for the directory names, or add local package archives to the sites file, then copies of the sites and configuration files must be made to the Software Base directory that is listed in the servrer's configuration file These local copies will override the server's copies.
As an example, suppose that the Software Base directory was listed as /opt in the server's configuration file. When the opt_depot scripts are run on the client, they will check to see if a file called /opt/opt.config exists (additionally, opt_link will look for /opt/sites). If /opt/opt.config was there, then variables specified in this local copy would be the ones that the opt_depot scripts use at runtime.
A good way to organize software is by creating sub-directories under /bin, /lib et al. for each operating system. For example, there might be /bin/winNT_bin and /bin/SunOS5.5_bin under the /bin directory of the software base. The advantage to doing this is that you insure every package that is found under a given operating system sub-directory is compiled to run on that particular operating system, and all the different flavors of a pakcges (for each seperate operating system) are still located under a single package heading.
The -r command line option that is used with opt_depot and opt_clean enables a feature known as recursive directory unification. If file conflicts occur during the linking process, opt_depot will check to see if it is worthwhile to make sub-directories under the software base directory, so that instead of having a single link to one package this subdirectory can contain links to files in both packages.
Opt_clean has also been modified so that when -r is used, it will remove empty subdirectories under the software base that have been created by opt_depot and are now empty, and will remove those directories that contain links to a single package and replace it with a single symbolic link to that package.
The main reason we included this feature was to unify the 'include' directories of packages like X11R5 and X11R6. But during testing we found that some directories were created that we really didn't want, and some directories were removed by opt_clean that needed to remain in place (even though they were empty at the time).
To deal with these problems, two steps were taken:
First, opt_depot explicitly states which directories are candidates for unification through the use of an array called path_list. If the list contained only "include/", then only subdirectories of "include/" will be able to be unified. The path_list variable is listed under the "defaults" section of the opt_depot source code.
Second, any time opt_depot creates a unifying subdirectory, it leaves a file behind to indicate that the directory was created by opt_depot and not by some other party. Opt_clean will only remove directories that contain this file, and will leave any other directories in place even if they contain no files.