[ On Tue, December 15, 1998 at 09:46:54 (-0500), Todd Vierling wrote: ]
> Subject: Package Paths Proposal v2
>
> 1. /usr is designed to be shared amongst multiple machines of a single
>    architecture. Therefore, in the default configuration, files that are not
>    exactly the same for all machines of a single archtecture should not go
>    here, and files that are written other than at package installation
>    should not go here.

There's a subtle mis-conception in there...  /usr isn't designed to be
shared amongst multiple machines of a single architecture.  It's
designed to be shared (in conjunction with /usr/share) amongst multiple
heterogenous machines.

I really wish hier(7) were written to specify /share and /local, not
/usr/share and /usr/local.  It would make this little distinction much
easier to grasp.

(Not that these issues are of much importance any more, except from the
point of view of keeping the system layout elegant and hygenic and in
making developers think about how to classify the objects they create.)

>     b) Special packages, such as those intended to replace system binaries,
>        should install binaries in $PREFIX, rename the appropriate system
>        files to `file.old', and use symbolic links to point to the proper
>        paths in $PREFIX.

This is a very good thing to specify clearly so that every package does
the same thing in this regard....

However I think the original proposal's idea of /pkg was much better in
that (if I remember correctly) it made it possible to have packages
install in /bin and /sbin (eg. if $PREFIX is set to / or if /pkg -> ..)
too without having to go to a whole lot of extra steps which will invite
package developers to make incorrect assumptions about the structure of
the system outside of $PREFIX and what they're permitted to do out there.

> 3. Configuration files: Programs use configuration files from /etc (not
>    $PREFIX/etc) as the compiled-in default. Generally, subdirectories
>    (/etc/<pkgname>) should be created for packages that have more than one
>    or two config files. Sample configuration files should be placed in
>    $PREFIX/share/examples/<pkgname> (pkgname may be omitted if a single,
>    uniquely named config file is used). The general algorithm for
>    installation is:
> 
>     a) See if example config files exist in $PREFIX/share/examples. If they
>        do, rename them with a .old extension. (This facilitates a later
>        diff3(1) or merge(1) to see and deal with configuration options that
>        are new or changed when a package is upgraded.)
> 
>     b) Install sample config files in $PREFIX/share/examples/<pkgname>.
> 
>     c) See if `real' configuration files exist in $PREFIX/etc. If not,
>        copy the sample config set over to $PREFIX/etc.
> 
>     d) See if `real' configuration files exist in /etc.  If not, add
>        symlinks for each from /etc to their corresponding files in
>        $PREFIX/etc.

Yuck.  Way too many symlinks.

Let's decide once and for all that either package config files go in
$PREFIX/etc or in /etc.  One or the other.  And remember that if you set
$PREFIX=/usr then you get 

It's bad enough having symlinks between the "traditional" config files
and the SysVr4 / SunOS-5 config files in /etc and /etc/inet:

lrwxrwxrwx 1 root    12 Jan  2  1998 /etc/hosts -> ./inet/hosts
lrwxrwxrwx 1 root    17 Jan  2  1998 /etc/inetd.conf -> ./inet/inetd.conf
lrwxrwxrwx 1 root    15 Jan  2  1998 /etc/netmasks -> ./inet/netmasks
lrwxrwxrwx 1 root    15 Jan  2  1998 /etc/networks -> ./inet/networks
lrwxrwxrwx 1 root    16 Jan  2  1998 /etc/protocols -> ./inet/protocols

(not to mention the redundant and silly looking "./" prefix in the
links! ;-)

Putting in a mess of symlinks pointing to /usr/pkg/etc is an even worse
idea.

Symlinks are a crutch that should be thrown away at the earliest
convenience.

Perhaps one concession:  /etc/pkg -> $PREFIX/pkg/etc

> 6. Startup scripts: daemons that start at boot time should have a start/stop
>    script available. This should be placed in $PREFIX/share/rc.d/<pkgname>.

Putting programs, even if you are willing to assume they are scripts,
under .../share/ is a *bad* idea.

Put them under $PREFIX/sbin (they *are* meant to be run by hand too!)
and put the real daemon binary in $PREFIX/libexec.

Mind you, the scripts you outlined contain no really interesting policy
decisions and I'd be just as happy to see "start/stop/reload"
functionality be built into daemons so long as we're going to stick with
the existing functionality of daemon(3) -- it need only be extended a
bit to do all this stuff in one common fashion.

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>