🚀 go-pugleaf

(I've included the material from the previous articles at the bottom of this
one).

I've decided to use /usr/local/gnu as the root of all my gnu software; I've
got the following subdirectories there:

	bin	Executables of course -- this is what users can add to their
		path. I keep it at the front of my path, so the GNU
		utilities override the normal UNIX utilities.

	doc	Random manuals that are neither info format nor man pages;
		right now I've got the manuals for elvis, gdbm, gnugo,
		gnuplot, and oleo stuffed in there.

	emacs	What's left of the GNU emacs build tree after I've whacked
		out the stuff that isn't needed at run-time. Mine seems to
		have etc, info, lisp, and tmp; the info directory there is
		just a symlink to ../info.

	etc	Miscellaneous admin programs, daemons, and so on.

	include	Header files for GNU add-on libraries.

	info	The info database -- since it's used by the standalone
		``info'' program and xinfo, as well as the original elisp
		info browser, I decided to lift it out of the emacs
		subdirectory.

	lib	All the lib support stuff for all the GNU packages. Most of
		the stuff there is for gcc and g++, but add-on libraries
		live here, as do support routines for other programs.

	man	A separate man tree for the GNU stuff. Let's hear it for
		MANPATH.

	src	I keep something that looks very similar to the contents of
		prep.ai.mit.edu:~ftp/pub/gnu in here.

	texinfo	The sources that I formatted up to make the info tree -- I
		keep them together here so I can make hardcopy manuals and
		so on.

Now I wanted to be able to support multiple architectures with a minimum of
duplication, so I went a little further. These directories actually live
somewhere else (on my system in /nfs/gnu) under a tree that everyone
NFS-mounts, which looks like this:

	bin-mc68020  emacs-mc68020  etc-sparc lib-mc68020 man
	bin-sparc    emacs-sparc    include   lib-sparc   src
	doc          etc-mc68020    info      lisp        texinfo

All that lives in /usr/local/gnu is a set of symlinks to the appropriate
directories in /nfs/gnu for the local architecture. This setup made it easy
to go ahead and build and install all the packages on each architecture,
then run a comparison routine and replace all duplicates from one
architecture to another with hard links. I've since distributed this
prepared build tree to several other systems and had it drop in with a
minimum of pain.

I of course look forward to the age when we have a GNU kernel and we can
abandon UNIX altogether, at which time I shouldn't be surprised if this
stuff ended up spread over {,/usr}{/etc,/bin,/lib} with sources in /usr/src.
Meanwhile, this layout seems to keep it all neatly organized, and neatly
isolated from the rest of the system.

-Bennett
(date < September 14, 1991) ? bet@orion.mc.duke.edu : bet@sbi.com

In article <1991Sep11.014654.26026@cunixf.cc.columbia.edu> jml12@cunixa.cc.columbia.edu (Jonathan M Lennox) writes:
>In article <9109110000.AA00264@wubios> david@wubios.wustl.edu (David J. Camp) writes:
>>In Reply to this Note From: <John Woods>
>>>
>>>Question
>>>========
>>>Is there a standard directory structure to be used with Gnu project
>>>stuff?  Where do I change names, put links, binaries, manpages?
>>>
>>I have most often loaded gnu stuff in the /usr/local subdirectory, but
>>when the full gnu environment becomes available, this will no longer
>>be appropriate.  I suggest that most gnu stuff be loaded at /usr/bin,
>>/usr/lib, etc. when using gnu itself, with /usr/local reserved for 
>>other stuff.  -David-
>>
>  Yes, but when one is working on some other system, but with a lot of
>gnu stuff (so much that it becomes inappropriate to have it all in
>/usr/local), what should one do?  Is /usr/gnu appropriate (in analogy
>with /usr/ucb)?  (This would be /usr/gnu/bin, etc., obviously.)
>
>Jonathan Lennox
>jml12@cunixa.cc.columbia.edu