[ On Wed, March 15, 1995 at 03:47:17 (-0600), vax@ccwf.cc.utexas.edu wrote: ]
> Subject: Re: Wher do binary packages go.
>
> 2) If makefiles/scripts were smarter, you could "uninstall" packages easily.
> And keep track of what files are in what package.  I can't count the number
> of times I looked in my bin directory and thought, "what is THAT for?".
> Now that I think about it, it might not be the right question for Makefiles;
> they might be more suited for "what files are in this package, and where
> are they installed?"  Basically, makefiles and scripts could take a great
> burden of documentation off the file system tree.  Haven't looked into
> binary packages yet, since I'm a CVS/source code kinda guy.

In software configuration management circles there is a concept of
building several trees of files to represent a product and to use
appropriate tools to distribute, install, track, each type of tree.

In the simplest case there might be a source tree and an install tree.
The source (and intermediate products) goes into the source tree, and
final products go into the install tree.

Ordinary source control and configuration tools such as RCS/SCCS and
make will suffice to manage the source tree.

The install tree can then either be treated as a bundle that get's
tar'ed up, and un-tarred on the target machine in "standard" locations,
or it can be mangaged with binary configuration management tools.  One
good example of such tools is the PKG tools supplied with UNIX SysVr4.
These tools track each file that's a part of a package and can be made
to understand rudimentary dependencies between packages.  They know how
much space will be required in the target system, how to install the
package files in place on the target system, how to manage the installed
file permissions, and even perform verification of the installed files.
Finally they know how to remove an installed package, also taking into
consideration rudimentary dependencies between packages (i.e. an install
of one package might create a /usr/lib sub-directory that's also needed
by a subsequently installed package, but removal of the first package
will not cause removal ofthe /usr/lib sub-directory required by the
second package).

[[ Of course full software CM where multiple developers and multiple
releases are involved is far more complex than this simple scenario! ]]

-- 
							Greg A. Woods

+1 416 443-1734			VE3TCP			robohack!woods
Planix, Inc. <woods@planix.com>; Secrets Of The Weird <woods@weird.com>