Dave Lorand <[EMAIL PROTECTED]> writes:
> Do you install each package in a separate volume per @sys, or do you
> have a common volume containing all architechtures? This seems to be
> the major issue about which folks here have waflled in the past. Some
> packages, like Matlab, seem to go better if there is a separate volume
> for each architechture because the authors wrote with single-platform
> installations in mind. Others, like Perl and Sendmail, expect to mingle
> architechtures within their trees, and they know how to separate
> architechture-specific files from architechture-independant ones. I'd
> appreciate anyone's comments on this issue.
We install each program in its own volume, and inside each volume is an
@sys breakdown as well as a share directory that holds things common to
all @sys values. We then use an automated tool to build a link tree into
all of the installed packages.
On this general topic, here's something I wrote up a while back for
internal documentation purposes that may be of interest:
The basic motivation behind a package setup is that you really want
installed programs organized by two different criteria at the same time.
For installation and administration reasons, you want each program to be
in its own package, so that all files related to one program are in the
same place, can be updated as a unit, can be moved around as a unit, and
so that one can tell what package any given installed file belongs to.
For use reasons, you want to have all executables in one directory (for
user PATHs), it's convenient to have one place to look for all libraries,
and so forth.
The structure used to resolve this is one of a set of volumes (one for
each installed package) and a directory tree that consists only of links
into those volumes.
Looking in <cell>/site/sweet/volumes, you can see the volumes for all of
the installed software packages. All of the files associated with
Mathematica are in <cell>/site/sweet/volumes/Licensed/math3.0.1, all of
Gauss 3.2.35 is in <cell>/site/sweet/volumes/Licensed/gauss3.2.35, and so
forth. Note that this allows multiple versions of a package to coexist
easily; Gauss 3.2.23 and Gauss 3.2.35 are both there, for example, just in
different directories. Note also that this allows each package to have
its own AFS volume (and therefore be released separately and so forth),
with the mount points in <cell>/site/sweet/volumes/Licensed. The layout
of the software in each package mimics how it is linked in (in other
words, there's a bin directory, lib and man directories as needed, and so
forth).
Now, looking in <cell>/site/sweet/systems, you can see the other half of
the picture. Under this directory is the standard set of directories for
each different architecture we support, and under there are the standard
set of directories for /usr/local. <cell>/site/sweet/systems/@sys is
/usr/local on the workstations, so /usr/local/bin maps to
<cell>/site/sweet/systems/@sys/bin.
Before going down into that directory, though, notice that there is an
<cell>/site/sweet/systems/@sys/volumes directory. If you look in that
directory, you'll notice that it's actually exactly the same directory as
<cell>/site/sweet/volumes. The volumes area is mounted in both places
so that the link structure can be built.
To see why this is necessary, look in <cell>/site/sweet/systems/@sys/bin.
Notice that every file in this directory is actually just a symlink. In
fact, *everything* under etc, include, lib, bin, sbin, apps, and so forth
in <cell>/site/sweet/systems/@sys is just symlinks into the appropriate
volume (as mounted under <cell>/site/sweet/volumes). This allows all of
the binaries to show up in a place convenient for the users, but still
allows us to keep all the files relevant to a given package together in
one place. It also means that the package volumes themselves can be put
anywhere in the file system, since the only hard-coded paths point to
directories under /usr/local.
If you look at the symlinks in <cell>/site/sweet/systems/@sys you'll
notice that they aren't into the full AFS path (since that would break the
ability to move the volumes around and do things like link /usr/local in
as /usr/sweet). Instead, they're all of the form ../volumes/.... The
symlinks point into <cell>/site/sweet/systems/@sys/volumes, which is the
same as <cell>/site/sweet/volumes. To understand the reason for this,
keep in mind that <cell>/site/sweet/systems/@sys is *really* /usr/local.
The symlinks therefore all point into /usr/local/volumes (rather than
trying to point into some full AFS path). This simplifies the structure
and makes things a little bit more obvious for the users.
The above layout (with a systems directory containing the link trees and a
volumes directory containing the actual software package volumes) is what
we'll use for <cell>/site/leland. pubsw is slightly different, in that
the volumes directory is called package instead (hence /usr/pubsw/package)
and is mounted on <cell>/pubsw. <cell>/systems is the systems directory
for pubsw and newsw (and also contains the AFS binaries).
--
Russ Allbery ([EMAIL PROTECTED]) <URL:http://www.eyrie.org/~eagle/>
