[ On Wed, December 16, 1998 at 08:07:27 (-0500), Todd Vierling wrote: ]
> Subject: Re: Package Paths Proposal v2
>
> Actually, /usr *is* meant to be shareable among machines of the same
> MACHINE_ARCH.  We're trying to go through a good deal of work to make sure
> that is the case.  Disk may be `cheap', but sharing is cheaper.

OK, I've said that too, but that design goal in itself doesn't explain
the reason for having /usr/share.  If that goal were the only one then
it would make more sense to simply push /usr/share back up a level and
shorten paths to its contents once again.

However sharing /usr/share in heterogeneous networks is harder to set up
(conceptually so, even more so, with it being under /usr) and doesn't
really offer much value in today's environment.  In reality every
diskful server is likely to have it's own local copy of /usr/share
anyway.

> : 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
> 
> No.  If something wants to replace system binaries in /bin and /sbin, its
> behavior is spelled out here, via the move-and-symlink item.

This isn't "easy" to do for some packages, esp. those that compile in
their paths.  For example GNU Autoconf coding standards don't expect a
separate /sbin and /usr/sbin, and anyone wanting to replace a system
binary will have to jump through extra hoops if they're using autoconf.
For example I've "autoconf'ed" a fingerd replacement.  I still don't
really know how I'd properly patch that thing to work with pkgsrc.  I
think anything that expects this to work right iwht pkgsrc will have to
have additional gunk in the pkgsrc Makefile or some additional install
script in the files subdir.

However if the pkg system is "leveled" out so that it lives, by default,
in /pkg (with both /pkg/bin and /pkg/usr/bin, for example), then it's
trivial to install such a package in place of the existing system
binaries by either pointing "/pkg -> ..", or perhaps temporarily
setting LOCALBASE=/.

I.e. if pkg is to follow hier(7) to the letter then it must be a
*complete* mirror and include $PREFIX/usr/sbin as well as $PREFIX/sbin.

> : 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 
> 
> .../usr/etc.  (Cut-off?)

Hmm.... yes that's what you get, but I thought the original proposal had
a solution to this all figured out...

> They go in /etc, and some people want to share many config files.  Hence the
> proposal.

As has been mentioned it would be *insane* for the pkg system to provide
a solution for sharing pkg config files, but not a solution for sharing
system config file.  Anyone who *knows* what they're doing, and *still*
wants to share *some* config files will almost always want want to share
some system config files too, and if the pkg system provides a
hard-coded solution to this problem it will likely clash with what they
want to do.  This requirement should *not* be dealt with here.

> : Perhaps one concession:  /etc/pkg -> $PREFIX/pkg/etc
> 
> So that pkgified stuff uses different config files than `out of the box'
> stuff?

OK, forget I ever suggested that.  I thought I'd deleted that line, but
it must have been from a separate followup.

> : Put them under $PREFIX/sbin (they *are* meant to be run by hand too!)
> : and put the real daemon binary in $PREFIX/libexec.
> 
> Um, they shouldn't go directly under $PREFIX/sbin - talk about `littering
> namespaces'.

*I* don't really care about "littering namespaces" actually.  I got over
that idea way back when C permitted the same field names to be used in
multiple structs, if not before.

But anyway, who said the name of the program in $PREFIX/libexec has to
be the same as the name of the wrapper script in $PREFIX/sbin?????  I
sure didn't -- I just didn't explicitly say it should be different,
mostly because I don't think it has to be different, but it could be
different if enough people feel they'd get confused (probably because
the silly fools are putting libexec directories in their PATH when they
shouldn't be).

-- 
							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>