Discussion: FS tree for large packages

Discussion: FS tree for large packages

Post by John B. Thi » Tue, 13 Oct 1992 19:45:48



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

--

UUCP    ...{sun,tektronix,verdix}!ogicse!jbthiel

 
 
 

Discussion: FS tree for large packages

Post by David W. Summe » Fri, 16 Oct 1992 07:26:47




>where large packages should be installed.

>There are two approaches when deciding where programs should go during
>installation: 1) maintain compatibility with other systems and
>familiarity for users, and 2) do it "right", even if it is different
>from everybody else.

>There are undoubtedly a large number of people on either both side.  I
>personally lean towards the traditional approach, since it leads to
>fewer problems when porting programs, and also because putting packages
>into lots of different places leads to huge PATHs, MANPATHs, info-paths
>(for GNU info), etc.

>I would personally prefer to have a scheme where packages are installed
>in such a way that all installed files are logged into a database, which
>can be used during uninstallation to decide which files should be
>deleted.  I have played around with a few ideas to implement this, but
>don't have the time to make it work properly.

>--


This (database) sounds like a good idea to me.

Here is another thought:

I haven't tried it yet, but SunOS has a "Translucent File System" where
multiple directories can be "stacked on top" of each other and made to
look like one directory.

Maybe something like this could be implemented and then each directory
that has information for a certain package (bin,lib,etc, and etcetera)
could be stacked on top of or below the original file system directories?

Is this feasible?

   - David Summers

**** Great Ideas, waiting to be shot down.... ****

--
                         "Never under-estimate the bandwidth of a station-wagon
David Summers             full of tapes, hurtling down the highway."


 
 
 

Discussion: FS tree for large packages

Post by E » Fri, 16 Oct 1992 23:17:36


: I would personally prefer to have a scheme where packages are installed
: in such a way that all installed files are logged into a database, which
: can be used during uninstallation to decide which files should be
: deleted.  I have played around with a few ideas to implement this, but
: don't have the time to make it work properly.
:
DRS/NX for ICL DRS6000 does this.  It makes life so much easier for adding
and installing packages as each package comes with its own install and
uninstall scripts.  I can get more details if anyone is interested.
--

Dept. of Elec. Eng.      |
University Of Surrey     |  Witty comment will be available when I'm feeling
Guildford. ENGLAND.      |  more witty.
 
 
 

Discussion: FS tree for large packages

Post by David W. Summe » Wed, 21 Oct 1992 02:04:42


ee89jje%ee.surrey.ac.uk (Ed) writes:

> I would personally prefer to have a scheme where packages are installed
> in such a way that all installed files are logged into a database, which
> can be used during uninstallation to decide which files should be
> deleted.  I have played around with a few ideas to implement this, but
> don't have the time to make it work properly.

SunOS Solaris 2.0 is supposed to have an /opt directory tree for packages
other than the base system...maybe we could investigate how they are going
to do it and do something similar?  The above mentioned installation is
just something I picked up from one of the free magazines (rags?) that
I get.

   - David Summers

--
                         "Never under-estimate the bandwidth of a station-wagon
David Summers             full of tapes, hurtling down the highway."