The CSL Software Installation Scheme

Introduction

This document discusses /s, the scheme adopted by the Computer Systems Lab for installing software on our Unix systems. The first part of this document is a users' guide, describing how to use /s. The second part discusses why we adopted this scheme and a little bit about how the software is installed.

We recognize that a change of this type is disruptive to our users, and apologize for any inconvenience it causes. We believe that it is a significant improvement over the previous scheme

If there is any software that is not installed in /s that you would like the Systems Lab to install, please send electronic mail to lab@cs.wisc.edu. The more information that you can provide about the requested software the better.

The Standard Path: /s/std/bin

To get all the standard software, put /s/std/bin in your path. If you put it before /bin, /usr/bin, and /usr/ucb, you will get the versions from /s before the vendor-supplied versions of similar programs (such as grep).

If you put /s/std/bin in your path before /usr/sup and /usr/psup, you will get the latest versions of software (installed in /s), and, if there is no version in /s, you will get the old version from /usr/sup or /usr/psup.

/s/std is a synthetic package containing the current stable recommended versions of most of the software in /s. Some programs that are not for general use are not included in /s/std/.

Finding Software

If you are not sure where some software is installed on the system, try the whatdir command. It will look in all the likely places for a program matching the name you give on the command line, and report all places that it can be found. Unfortunately, whatdir runs very slowly.

In addition, you can look for package names (and version numbers) in /s, using the ls command. This is much faster than whatdir, but only reports programs in /s, not the vendor-provided directories.

Motivation

Our motivation in switching to this installation scheme was to provide a more reliable yet flexible set of software to our users.

Problems with the Old Scheme

We identified the following problems with the previous installed scheme (/usr/sup, /usr/psup):

• It was difficult or impossible to have multiple version of a software package installed side-by-side.
• Users had to maintain very long and complex path variables
• Different versions or configurations of the same software was installed on different architecture
• There were several different places for users to hunt for a program
• Software was installed inconsistantly: Some programs were installed as separate packages, while others were installed directly in /usr/sup/bin or /usr/psup/bin

Advantages of =/s

We see the following advantages to the /s installation scheme:

• Multiple versions of a software package can be installed side-by-side
• Already installed software is not disturbed by the installation and testing of new software (because each software version is installed as an independant package).
• More uniform software available and versioning across architectures
• There is only one place to look (on any system, for all architecture) to determine if a package is installed.
• The sources (if available) and other supporting online materials for a package are with the software
• It is easy for a user to tell what version of a program is being run

Software Packages

We have divided our software into packages. Usually a package is easily defined by the provider of the package. For example, the Free Software Foundation (GNU) has divided their software into packages. One such package is sh-utils which contains shell utilities (basename, date, etc). Another GNU package is grep, which is the grep family of commands.

In some cases a package has only a single program. In other cases we have created a package to hold several different programs that are all related in some way (such as srctools, which has patch and shar in it).

Each package is installed in /s in a directory with the package name and version number. Everything related to the package is in the package directory -- binaries for all supported platforms, libraries, documentation, and the source (if available).

The current stable version of a package is always available via a symbolic link from the package name (with no version number). For example, /s/gcc is a symbolic link to /s/gcc-VERSION-NUMBER.

Package Structure

Packages make use of the AFS @sys mechanism, which allows a symbolic link to be resolved differently when referenced on different operating systems.

Each package has the following files and directories in it:

• bin a symbolic link to the bin directory for the current system (@sys/bin)
• man a symbolic link to the man pages for the current system
• common a directory containing common files (for all systems)
• ChangeLog a file giving the history of the software, configuration options, and notes about known problems

In addition, packages often contain the following directories:

• src the sources to the program, if available
• lib a symboic link to the system-specific libraries
• depend a directory containing symlinks to other software that this package depends on.
• info the GNU info files for the package
• doc additional documentation for the package
• subdirectories for each operating system and hardware platform. You can use the AFS command fs sys to find out your current system name. You do not have to put the system-specific directories in your path, the symbolic links to @sys/bin should take care of that for you.

Synthetic Packages

In addition to the packages described above, we have created synthetic packages, which are a combination of two or more packages. An example of this is /s/gnu, which is all the GNU software. The most important synthetic package is /s/std, which has almost all the software from /s.

Synthetic packages are maintained by automatically building a tree of symbolic links to the actual software from the bin and man directories of the synthetic package. If you want to see what this looks like, change directory to /s/gnu/bin and issue the ls -l command.