|
Briefly, /apps contains a directory for each software package. Below that directory is a subdirectory for every version of that software package. Within that subdirectory are the necessary components of that version. This might include yet another level of directories for binaries, libraries, and documentation. We use a few judiciously selected symbolic links to hide this complexity from the user in the most common cases. For example, /apps/gcc/bin/gcc is always the preferred verion of gcc, and /apps/emacs/bin/emacs is always the preferred version of emacs.
Since each package is separated into its own hierarchy of directories, we gather together symbolic links to all the current versions in /apps/bin. This is in the default path.
Now for the details:
/apps is a symbolic link to a directory of links, usually /apps -> /u/apps/links Consider a software package called "foo" /u/apps/links/foo -> /u/apps/foo Here's the symlink trail: /apps/foo -> /u/apps/links/foo -> /u/apps/foo Suppose that we use two different versions of foo, foo-1.2.2 and foo-1.2.3. Here's a map of the directory structure: /apps/foo PRO -> foo-1.2.3 [specifies that foo-1.2.3 is the production version] foo-1.2.3 bin BUILD -> foo-1.2.3 (yes, /apps/foo/foo-1.2.3/foo-1.2.3 ) [complete source tree under BUILD] lib man include etc [...] foo-1.2.2 bin BUILD -> foo.1.2.2 (yes, /apps/foo/foo-1.2.3/foo-1.2.3 ) [complete source tree under BUILD ] lib man include etc [...] bin -> PRO/bin lib -> PRO/lib man -> PRO/man include -> PRO/include etc -> PRO/etc /apps/bin/foo -> /apps/foo/bin/foo /apps/man/man1/foo.1 -> /apps/foo/man/man1/foo.1 /apps/lib/foo.so.3 -> /apps/foo/lib/foo.so.3
log into a machine with the proper OS
cd /apps
[working dir is now /u/apps/links]
ln -s /u/apps/flex /apps/flex
[unless it already exists. We want /u/apps/links/flex -> /u/apps/flex]
[This is one of the VERY few times you want to explicitly use "/u/apps" instead of /apps]
cd /u/apps
mkdir flex
[unless it exists becuase there are other versions under it]
cd flex
[working dir is now /u/apps/flex]
mkdir flex-2.5.4
[this creates the root for the new version of flex]
ln -s flex-2.5.4 PRO
[if this is the production version. you might do this later]
cd flex-2.5.4
gtar xvfz /site/ccc/downloads/ftp.flex.com/flex-2.5.4.tgz
[creates ANOTHER flex-2.5.4 directory this is the BUILD directory]
ln -s flex-2.5.4 BUILD
cd BUILD
./configure --prefix=/apps/flex/flex-2.5.4
[It's important to use "/apps/..." here, NEVER "/u/apps/..."
[... configure output ... If there's no configure, do the same by hand]
make
make test
make install
[puts binaries in /apps/flex/flex-2.5.4/bin]
cd /apps/flex
ln -s PRO/{bin,lib,info} .
[if this is the first production version, make the PRO links]
Now you have a complete build of flex-2.5.4 under its own directory structure.
You have not disrupted any existing versions, nor have you changed the default.
Regardless of wheter this is the default version or not, you must create a setup
configuration file for this new version. See the next section.
To change the production version, only one symbolic link, the PRO link, needs to change. Consider this example where there are two versions of the famous foo package: foo-1.2.2 and foo-1.2.3. The current version is 1.2.2, and we want to change to 1.2.3 as the production version:
cd /apps/foo rm PRO; ln -s foo-1.2.3 PROTo support the older versions, you will likely want to add a use.conf file to /site/cuesw/foo/foo-1.2.2 so that "use" (the replacement for setup) can make older versions available.
#!/bin/sh MOZILLA_HOME=/apps/communicator4.5;export MOZILLA_HOME exec /apps/communicator4.5/netscape http://www.jlab.org >/dev/null 2>&1This small script sets the necessary environment variables and then executes netscape. The "exec" will make the netscape process overlay the wrapper script. This prevents an extra process slot from being consumed by the wrapper script once its function has been completed.
Packages that are built to be installed in /usr/local: /apps/LOCAL contains packages that are built and ready to be installed in /usr/local with a "make install" (or whatever is appropriate for that package). The structure can be different from the rest of /apps since people can pick and choose which package to install. A flatter file system layout can be used, e.g. /apps/LOCAL/ssh-1.2.25 /apps/LOCAL/ssh-1.2.26 /apps/LOCAL/tar-1.2.11 /apps/LOCAL/tar-1.2.12 and so on. The idea is that we don't need the extra tree structure because nobody is going to use "setup" to get around with these packages in /usr/local/ If people want to have alternate packages in /usr/local, we can leave that as an exercise to the reader. I suggest that we should only support multiple versioning using setup in /apps. /usr/local is more proflexy the domain of any local system administrator-- they deicde the layout and details.
This document is maintained by {helpdesk@jlab.org}
Copyright Jefferson Lab 2007