[ On Mon, August 3, 1998 at 09:52:06 (-0400), Perry E. Metzger wrote: ]
> Subject: Re: use of share vs lib 
>
> Todd Vierling writes:
> > : And btw, it MUST leave those files in /etc/ for configuration reasons.
> > 
> > That's not necessarily true.  I was always of the opinion that we should
> > have adopted FreeBSD's convention of putting them in ${PREFIX}/etc - after
> > all, everything else has its config info there, so why not ssh?
> 
> Because /usr gets cross mounted between machines of the same
> architecture in many setups, and you don't want multiple machines to
> be forced to share the same configuration.

Perry you've got your blinders on!  ;-) This problem is *easy* to solve
with either symlinks or loopback mounts.  That is of course *if* you
need to solve this problem.

The fact that there is a problem to solve does beg the question....

If pkg "var" stuff just goes in /var (or /var/pkgname if appropriate),
why not just drop pkg config stuff directly in /etc (or /etc/pkgname if
appropriate)?

One might even wonder why pkg binaries and such are installed in
/usr/pkg even.  The original idea behind having a separate hierarchy
mirrored under /usr/local or wherever was so one could easily identify
and separate what came from where (for various purposes, such as
upgrades, finding out who to call for support, etc.).  With the pkg
system there's a database constructed to identify which files come from
which packages and even give rudimentary dependency data.

I once set up a multi-architecture distributed system with as many
shared files as possible, but without the benefit of a package
management system.  I complicated things, probably unnecessarily, by
building system hierarchies, /local hierarchies, and /contrib
hierarchies for pre-ported software available from the OS vendors.  I
didn't think this was too difficult or complex, but then I took a look
at a system where this concept was taken to its ultimate end -- i.e.
Solaris with the /opt hierarchy where *every* package has it's own
sub-directory and then only if necessary are symbolic links used to
provide convenient and easy-to-remember pathnames for users and
administrators.  That experience convinced me that this way lies madness
and that the better solution is to use a package management system (and
the NetBSD pkg_* tools seem mostly sufficient) and ideally everything
should be installed and fully integrated into the normal system
hierarchy.  After all, what's the logical difference between a package
being integrated by the NetBSD core team, and me as an administrator
integrating some package?  Well, to answer my own question the only
difference is origin of the integration effort, and thus who's going to
support it and how it will be upgraded.  So long as there exists some
mechanism to identify where a file comes from and what interdependencies
it has, it doesn't matter how intermingled packages and system files
become.  (Which further begs the question of why the OS install isn't
done using the pkg_* utilities....)

I suppose my plan is easy to implement if I just set PREFIX=/.  However
this would imply that either: pkg config files must be put into
${PREFIX}/etc and pkg run-time files must be put into ${PREFIX}/var; or
config files always be placed in /etc and run-time stuff in /var, with
no variations.  With the former if people want the best of both worlds
they can install symlinks or loopback mounts into the "standard" places
and thus still be able to share /usr (and /usr/pkg!).  I think though we
need some consensus and a strict guideline to make this work one way or
the other.

(BTW, I currently install pkgsrc packages into /usr/pkg because I don't
100% trust the system yet, and I have a /usr/local for my own hacking.  ;-)

-- 
							Greg A. Woods

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