Each software package is placed in its own subtree, and all of these subtrees reside under a single parent directory. The tree which houses all the packages is called a depot. If a depot is publicly accessible then it is usually called a server. Typically a server houses multiple distributions (i.e. releases) of software packages. Software is made publicly available for execution by creating links inside a public tree which point to run-time files in the local depot. For more information, see the section on Terminology.
Earlier versions of LUDE required that packages be installed inside a very specific software depot, which was `/usr/local/soft'. However, in version 2.1 of LUDE this restriction has been removed so now you can install software packages inside any arbitrary directory (e.g. `/lude/depot', `/lude/soft', etc.).
Every version of a software package is treated as a different package with its own subtree. The unique name of a package is then formed by the concatenation of its name and version number (e.g. `emacs-19.29', `gcc-2.6.3'). This allows multiple versions of the same software package to coexist peacefully during transitions, and simplifies the management of disk space since each package is kept separate.
Inside each subtree, three subdirectories are present (`src', `run' and `install'), as well as a file (`history') which traces where the package was copied from.
Software-Version
______________________________|________________________
/ | | \
src run history install
___|___ ________|____ ___|___
/ | \ / | \ / | \
orig mod ... share mod ... share mod ...
_|_ _|_ _|_____________ ______|______
/ \ / \ / | \ / | \
class ... man ... class share ... class share ...
______________|____ _|_ |
/ | | | | \ / \ |
bin man lib etc info ... man ... afterinstall,systemdep,...
In each depot, a special directory is created, called `00-catalog'. This directory serves as a way to stock information about packages in a form that is more 'human-readable', like HTML. Right now, LUDE tools provide ways to generate HTML versions of the `IAFA-PACKAGES' and LUDE files, but also maintain a quick-access database file called `00-lude.idx', which represents every software package available.
The `src' subdirectory contains the source code. It is used to patch and compile the software, or simply for learning purposes, but is not required at execution time. The unmodified source code is in `src/orig' while one or more local variants may be stored in class sub-directories inside the modifications. These modifications can be as simple as editing a `Makefile', or more elaborate, like patching `gcc' to support Pascal and ADA preprocessors.
Each modification, for a given package, must have a unique name, other than orig. Often the name will identify the person or organization responsible for the modification, but most of the time the default modification name will be used.
For instance at the DIRO, for the software package `emacs-19.29', the original source code, downloaded from `prep.ai.mit.edu', is found in `/usr/local/soft/emacs-19.29/src/orig', while local modifications to support the French language and other features specific to the DIRO are found in the `/usr/local/soft/emacs-19.29/src/iro' subtree.
LUDE provides ways to create a complete copy of the original source code (located in `src/orig') inside a specific class directory of a requested modification subtree. After the modifications are compiled, to conserve space, unmodified files are removed from the copy such that only locally modified files remain in the modification subdirectory.
It is up to the person compiling a package to select an appropriate modification name. It is important, however, to use the default modification name whenever possible, and try to make the package as general as possible. LUDE provides ways to relocalize configuration files after an installation is complete, so most issues are resolvable, even if the package is not installed inside the same depot as forseen by the ludifier.
The files in the `src' subtree can be compressed if infrequently accessed, in order to reduce disk usage. This way, the source code will still be accessible. It is not acceptable, however, to archive the source code in a single file (using tar(1) for instance) or, even worse, on tape. You should not assume that no one is interested in source code. Moreover, some software copyrights require that the source code be available.
The `run' directory in a package subtree contains, for each modification and class, all the files required at run time. These include the executable files (`bin'), include files (`include'), libraries (`lib') and documentation (`man', `info' or `doc'). Symbolic links in the public tree (normally `/usr/local') to the corresponding files in `run/modification/class' make these files easily accessible to users. Because of these links, a user only needs to put the public `bin' directory in his or her shell execution path, even though each software package is actually kept in a separate subtree.
This implies that many computers sharing the public tree will see the same symbolic links and will necessarily access the same class and modification for each software package.
A user, however, may choose to put the `run/modification/class/bin' subdirectory of some package in his path, if he or she wants to use a different version of the package than the one currently linked into the public tree. This way, a user may use a newer version of a package before others do, or may continue to use an older version even after it has been unlinked from the public tree.
The following directories are usually found in the `run/modification/class' subtree:
* emacs: (emacs). The emacs extensible text editor
$DEPOT/emacs-19.29/run/default/share/doc/emacs-19.29/COPYINGfor which would appear the symbolic link
$PUBLIC/doc/emacs-19.29/COPYING
Sometimes, run-time files are class- or modification-independent. These can be placed in one of the `share' subdirectories at the appropriate level (`run/share' or `run/modification/share'). LUDE automatically creates symbolic links pointing to these files for each modification and class that uses them. This way, sharing remains transparent.
Here is an example of a `run' subtree for the package `bash', release 1.14.4, located in the software depot `/usr/local/soft'. Binary executable files are kept in a specific class directory:
/usr/local/soft/bash-1.14.4/run/default/sparc_sun_solaris2.3/bin: bash* bashbug*
Info files are shared across classes:
/usr/local/soft/bash-1.14.4/run/default/share/info: bash.info bash-1.14.4.dir
Some manual pages are shared across classes, but not all:
/usr/local/soft/bash-1.14.4/run/default/share/man/man1: bash.1 bash_builtins.1 /usr/local/soft/bash-1.14.4/run/default/sparc_sun_solaris2.3/man/man3: readline.3
It is almost always best to share architecture-independent files, especially since many software packages provide a means of doing so (`--prefix' and `--install-prefix' options).
The `install' subtree of a software package contains a structured description of the package, in a file called `install/IAFA-PACKAGES'. This file follows the format prescribed by the Internet Anonymous FTP Archive working group and contains a number of fields describing the software package; for more information on IAFA see on host ftp.cc.mcgill.ca:pub/iafa. See section `IAFA-PACKAGES' File for details.
For each modification, a file named `LUDE' exists inside the `install/modification' and `install/modification/class' directories. LUDE files are used to describe the steps needed to ludify the software. See section `LUDE' Files for a complete description of the file format of these files.
The directory `install/modification/class' may also contain some information about how to install the package, for this modification and class. This information is used by the LUDE tools. The following files may be present, when necessary:
See section Installation Scripts for more details.
LUDE provides two distinct ways of describing dependencies. First and foremost, system-based dependencies are handled by a script that is executed at the earliest possible moment. Its purpose is to verify the presence of certain system-based components. This script is not under the control of LUDE itself, and must rely on other mechanisms in order to complete the requested task. The name of the script is `systemdep', and it can be placed in any of the directories in the `install' subtree.
The other file handles LUDE-based dependencies. It is not a script, but rather a configuration file, which describes what is needed in terms of other LUDE packages, before this package can be installed. The name of this file is `ludedep'.
See section Dependency Handling for more complete discussion of dependencies can be found in a later chapter.
When an installation is done using LUDE, the software's run-time files are automatically symbolically linked into the public directory tree, which is normally `/usr/local'. Prior to version 2.1 of LUDE it was not possible to choose a location other than /usr/local for the public tree; this is no longer true. You can use any other arbitrary directory tree as the location of the links to the software's run-time files (e.g. `/lude', `/usr', etc.).
In earlier versions of LUDE corresponding symbolic links were made directly to run-time directories whenever possible, to minimize the number of links; with the current version of LUDE this is no longer true. Although there were advantages to doing this, it also caused problems. Now, instead of linking each run-time directory to the appropriate public location, LUDE creates a corresponding directory in the public tree (if it does not yet exist), then creates symbolic links inside the created directory to files present in the original directory.
Under LUDE, a computer can be both a client and a server. Moreover, a client can represent a light or heavy load for a server:
Typically, a multi-level client-server organization will be found, which operates as follows:
Normally, servers are available inside a specific directory, usually called `/usr/local/server'. At the DIRO, we have three servers, called `lude-iro', `lude-iro2' and `lude-iro-privee'; these subdirectories are all available inside the main server directory. Example:
% ls /usr/local/server lude-iro/ lude-iro-privee/ lude-iro2/ % ls /usr/local/server/lude-iro2 a2ps-4.3/ icon-9.0/ rtftohtml-2.7.5/ accent-1.0/ ilp-3.0/ rzsz-9103/ acroread-1.0/ ImageMagick-3.3/ satan-1.0/ autoconf-2.1/ iro_minimal-1.0/ screen-3.5/ bash-1.14.2/ ispell-3.1.08/ screenblank-25.08.93/ bash-1.14.4/ jpeg-5.0/ scsiinfo-1.0/ BibTool-2.22/ less-290/ sed-2.05/ bibview-2.1/ libg++-2.6/ sh-utils-1.10/ binutils-2.5.1/ libg++-2.6.1/ shar-4.0/ caml-light-0.61/ libg++-2.6.2/ sharutils-4.1/ cap60_pl194/ lost+found/ sox-10.11/ cern-httpd-3.0/ ls-lR.Z sun2mac/ diffutils-2.7/ lude-1.7/ sysinfo-2.1.3/ dvipsk-5.58f/ ludeweb-0.1/ sysinfo-3.0.1/ ed-0.1/ lynx-2.3/ tcl-7.3/ elisp-accent/ m4-1.4/ tclX-7.3a/ elisp-mime/ make-3.72.1/ test.c elm-2.4.24/ makeindex-2.12/ test.pl emacs-19.28/ mpeg-1.0.1/ texi2html-1.20/ eric-1.0/ mush-7.2.5/ TeXMF/ eric-2.0/ ncftp-1.82/ timex-1.95/ expect-5.13/ ncftp-2.0.7/ tin-1.22/ findutils-4.1/ netfind-4.6/ tk-3.6.1/ flex-2.4.7/ netscape-1.0/ webster-1.5/ fvwm-1.22f/ netscape-1.1/ xanim-2.68.3/ gas-2.3/ nntp-1.5.11/ xdvik-1/ gawk-2.15.5/ oleo-1.6/ xdvik-1.8/ gcc-2.6.3/ perl-4.036/ xdvik-1.8f/ gdb-4.13/ perl-5.001/ xemacs-19.11/ ghostscript-3.12/ perl-5.001e/ xlax-92/ glimpse-2.0/ pine-3.91/ xntp-3.4i/ groff-1.09/ procmail-3.10/ xntp-3.4n/ hotmetal-1.0/ ptx-0.4/ xpm-3.4b/ httpd-1.3/ recode-3.4/ xv-3.10/