From: jbthiel@ogicse.ogi.edu (John B. Thiel)
Newsgroups: comp.os.linux
Subject: Discussion: FS tree for large packages
Summary: (nothing to do with /usr v. /usr/local)
Date: 12 Oct 92 10:45:48 GMT
Article-I.D.: ogicse.43959
Distribution: world
Organization: Oregon Graduate Institute (formerly OGC), Beaverton, OR


Discussion: FS tree for large packages

[Note: nothing to do with /usr vs /usr/local]

The following discussion reflects my (perhaps mis-) understanding of
various file system administration issues. I am posting to invite
clarification, correction, and discussion. Any pointers to references
in which these and greater complexities of Unix file system
management are discussed will be appreciated.

(... = normal files, $(P) = / /usr/ /usr/local/ etc.)

[1]
$(P)bin/...
$(P)lib/...
$(P)usr/bin/...
$(P)usr/lib/...
$(P)usr/man/...
[etc]

This is the basic, traditional arrangement, well suited for individual
binaries with perhaps a few related lib files, but for multi-file
packages it has always struck me as a dangerously one-way scheme.
Files are easily added, but removing or updating a package can lead to
a frustrating uncertainty as to whether all of the related files have
been addressed.

Presumably in consideration of this issue, some larger packages (eg. FOO)
locate their files in 

[2]
$(P)bin/FOO/...
$(P)lib/FOO/...

This becomes difficult to follow when multiple, or unrelated,
directory names are used instead of the single 'FOO'.  The
latest GCC, for example, puts all normal libs in /usr/lib and the
shared libs in /usr/lib/shlib. Such usages are in themselves trivial;
my concern is the increased complexity as the number of instances
grows, and the introduced semantic inconsistency in the directory
names (ie.  we can easily assume usr/lib/groff/ holds support files
for groff; the contents of usr/lib/shlib are not obviously linked to
gcc, unless usr/lib itself is to be taken as wholly or primarily
devoted to compiler libraries).

The cleanest run-time tree for large packages seems to be that which
closely corresponds to a typical development tree, namely:

[3]
$(P)FOO/bin/...
$(P)FOO/lib/...
$(P)FOO/src/...
$(P)FOO/include/...
[etc]

This tree is readily explored and understood and easily installed,
removed, or updated. I note that at least a few large packages have
recently been released in this configuration (eg. X386 and emacs).

As a concrete example, my upgrade from the Xfree86 2.0 beta to 2.1
amounted to little more than the untarring of one tree and the rm-r of
another. (see \footnote 1)

===============
Questions then:

1.  Are we indeed moving toward method [3], away from the perhaps
historical method [2]?

2.  Default macros in Imakefiles suggest that even so large a
package as X originally used tree [2] above.  Are there technical
reasons why method [3] was not used in the first place?

3.  What advantages, if any, of [2] over [3]? One advantage that has
occurred to me would be the potential for very short PATHs if the
operating system (or shell) supported a recursive path context (ie.
PATH=/usr/bin would find executables in any subtree of /usr/bin). Do
any shells support such? It would be a useful feature to add to Linux
or its shells.

4.  What adv. of [2], given that [2] can be emulated from [3] with
symlinks?  eg. ln -s /usr/FOO/bin to /usr/bin/FOO

5.  What other points or observations apply?  In particular, I wonder
about the use of /usr/include as a general catch all for some vague
set of headers for the "system" compiler. If another compiler were
additionally installed, surely its headers, having perhaps duplicate
names, would have to go somewhere else. Would it not be more intuitive
to have the /usr/include headers already in a parallel place? eg.
/usr/gcc222d/include, usr/gcc14/include, usr/mod2/include, etc.

================

If, pending some discussion, we conclude that [3] does indeed subsume
[2], I would propose that we begin deprecating the bin-, lib-,
include-rooted subtrees in favor of package-rooted subtrees, for all
large (define large) packages distributed under Linux.  Documentation
or an install script can be provided to link the distribution into the
[2]-style paths, should this prove desirable.



(\footnote 1)
By contrast, I also recently upgraded to Gcc 2.2.2d/4.1 from the
mcc-interim 0.97p2 release. Gcc related files were scattered
throughout /usr/bin, /usr/include, /usr/lib, and multiple subtrees
thereof.  Not knowing exactly which to delete, I forebore, assuming
the existing files would be overwritten. Unfortunately, the two
releases used some different paths, resulting in a number of obsolete
duplicates remaining hidden in the file system, awaiting the effort to
track them down.

(no offense to H. Lu or O. LeBlanc. I have high praise and appreciation
for your work on gcc, the interim release, and other Linux projects).



John B. Thiel


-- 
CSNET	jbthiel@cse.ogi.edu
UUCP    ...{sun,tektronix,verdix}!ogicse!jbthiel
Newsgroups: comp.os.linux