The CSL Software Installation Scheme
This document discusses
, 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
. 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
that you would like the Systems Lab to install, please send electronic mail to email@example.com
. 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
in your path. If you put it before
, you will get the versions from
before the vendor-supplied versions of similar programs (such as grep).
If you put
in your path before
, you will get the latest versions of software (installed in
), and, if there is no version in
, you will get the old version from
is a synthetic package containing the current stable recommended versions of most of the software in
. Some programs that are not for general use are not included in
If you are not sure where some software is installed on the system, try the
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,
runs very slowly.
In addition, you can look for package names (and version numbers) in
, using the
command. This is much faster than
, but only reports programs in
, not the vendor-provided directories.
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 (
- 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
Advantages of =/s
We see the following advantages to the
- 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
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
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,
is a symbolic link to
Packages make use of the AFS
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 (
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.
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
, which is all the GNU software. The most important synthetic package is
, which has almost all the software from
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
and issue the