[63] in DCNS Development
Re: Filesystem Reorganization for release 7.3
daemon@ATHENA.MIT.EDU (Ralph Swick)
Wed Jul 10 13:21:01 1991
To: Mark Rosenstein <mar@MIT.EDU>
Cc: developers@MIT.EDU, release-73@MIT.EDU, cluster_managers@MIT.EDU
In-Reply-To: Your message of Tue, 02 Jul 91 18:25:03 -0400.
Date: Wed, 10 Jul 91 13:19:46 EDT
From: Ralph Swick <swick@ATHENA.MIT.EDU>
Some additional thoughts for your meeting tomorrow... (and assuming
some prerogative as not having actually "left" yet.)
It should be possible to layer Athena software on a machine already running the
vendor operating system. For this reason, Athena files should be added to a
small number of places, not scattered across the entire operating system.
I applaud this goal enthusiastically. Among other things, such an
organization can lead to a better understanding of "what comes with
Athena". I also foresee a future need to provide a workstation owner
an 'uninstallAthena' script. Any new proposed organization should
take this into consideration -- as does your proposal.
2. Third party software will go under /usr/athena/third
Some such grouping is definitely appropriate for the software that
comes with the Athena environment. It is not entirely clear to me
that exposing an "Athena- maintained" vs. "non-Athena-maintained"
division in the filesystem truly serves much purpose. This is not the
way we should be training users to think about the world. Rather, all
"standard Athena" binaries should just go into /usr/athena/bin. If
any distinction were useful to make, I'd suggest instead some variant
of /usr/athena/bin/unrestricted/ and /usr/Athena/bin/licensed/.
Initially, I hesitated on forcing third-party software into the
/usr/athena/ branch. Third party software frequently has its own
preferred location. This will often be exposed in user documentation.
Some users will arrive at MIT expecting to find certain common things
in their usual places. Granted, such software (and users) may be
making suboptimal assumptions.
Jon's later comments changed my mind on this question, though.
A workstation owner should be free to install his/her own copy of
any third party package. It will therefore install into its
default location (or other such non-/athena location of the user's
choice). This need may arise for a variety of reasons, including
1. user wants newer version than that currently offered by Athena
2. user wants older version " " " " " "
3. user wants version licensed differently ...
X and Motif are certainly examples of this. Whatever versions of X
and Motif are provided by Athena should not go into a place likely
to be used by the OS vendor, as we *know* that Athena's versions
will be different and there *will* be third party software that
depends upon one or the other.
(we are not
completely sold on the name ``third'',
I recommend /usr/athena/bin/unrestricted and /usr/athena/bin/licensed,
or some similar scheme that readily reminds users of what distribution
restrictions may apply. It should be clear to users through other
means which software is maintained by Athena and which is not. Naming
things such as Motif "third party" is particularly artificial, as the
Distributed Applications group is likely to continue to provide
substantial support to keep up-to-date with respect to OSF rather than
wait for vendors' product testing/release cycles. If the
third/non-third distinction is really important for some reason, my
suggested names would be (ignoring all precedent and trying to take a
fresh view:)
/usr/athena/bin/athena IS-provided Athena tools
/usr/athena/bin all other components of the ACE
The
notable exception to this is X11, which will go under
/usr/athena/X11/... since it is such a large subsystem.
Disagree. X executables should go into /usr/athena/bin/unrestricted/
or /usr/athena/bin. The X development environment should continue to
have a distinguished, but common, mount point (i.e. /mit/x11) so that
developers can continue to play with multiple revisions, as they
unfortunately still want (need?) to do. However, once attached the
libraries and headers should appear (via symlinks) under
/usr/athena/{lib/,include/X11}. The notion that X should be special
just because it's so big is of no significance to users -- they
shouldn't have to remember different paths for each "large" package.
There are not enough X binaries to be worried about the cost of
searching large directories; reasonable shells cache the results
and /usr/athena/bin/ is certainly not going to grow larger than /usr/ucb/.
Also, such a distinction would imply that the user-contributed X tools
should either go in with the rest of the "third-party" X binaries,
taking over an "vendor" directory, or must be separated in a way
guaranteed to cause continued confusion.
4. In some cases Athena must replace a vendor binary with an Athenized
version. In most cases we will leave the vendor binary in place,
and put our version in /usr/athena. The order of directories in the
user's PATH will ensure that they get the proper version.
I anticipate that there will be cases where the granularity of
ordering of PATH will be insufficient for some users' needs. I.e.
I may prefer the {OS,application} vendor's version of one package
in /usr/bin but Athena's version of some others in /usr/athena/bin.
I recommend that you design and document a specific standard way
for users to declare fine-grained overrides, for the sake of
consultants and other assistance providers. Symlinks in ~/bin
may be sufficient, but I suspect that ~/bin is already overloaded
with semantics and another name (e.g. ~/defaultbin) should be
suggested which can always be listed at the beginning of PATH.
Another way people with customizations may lose is by setting their own PATH
variable rather than by modifying the default one. People who just add to the
end of athena_path will have no problems.
There exist other environment variables with identical syntax and
similar semantics to PATH for which Athena has not provided
standard prefix values. In particular, I point to XFILESEARCHPATH.
(I think SoftPC also has such a variable that users may have had
the need/desire to change, but I don't specifically recall at the moment.)
I've no clever suggestions about what to do at this point, but the
documentation/posterization will need to factor this in.
-R
