[ On Thu, December 10, 1998 at 14:01:51 (-0800), Curt Sampson wrote: ]
> Subject: Re: /usr/pkg/etc vs. /etc
>
> True enough. But you've just made two assumptions that I'd like
> you to defend.
> 
> 1. There is nothing that should ever be shared in /usr/pkg/etc.

In many situations this is true (though I don't think it needs to be
true for systems where multiple servers all mirror each other, even for
the case of diskless clients in some configurations).

However I don't think sharability is the reason things might be put in
$LOCALBASE/etc/.  As someone has already mentioned, the reason
$LOCALBASE isn't set to "/" by default is because by default most people
don't seem to want to integrate local packages into the "system"
directories.  I know I don't want to do this, esp. not on my development
servers (though I *do* want to do this on some kinds of systems!).

(When a >4GB disk costs <=$400[cdn], even as SCSI, there should be
little, or no, need to share installed images across multiple
non-diskless hosts -- just share /usr/pkgsrc/packages and do the
installs on each machine!)

> Sample config files should not go there, nor should the startup
> scripts for applications. (This means, too, that it's not possible
> to upgrade the script that starts, say, Postgres or MySQL across
> all machines when you put in a new package.)

Anything that you'd put in /etc if it were integrated into the system
should be put in $LOCALBASE/etc if it's installed as a "package".

> I don't see the advantage of keeping every last bit of package-related
> stuff under /usr/pkg, except for people developing package stuff
> that want the ability to blow it all away easily.

Then you should set "LOCALBASE=/" in your /etc/mk.conf file.

> We don't normally
> separate the configuration files for NetBSD and non-NetBSD programs
> (most everyone puts the configuration files for /usr/local/sbin/sshd
> in /etc, for example).

SSH is a *bad* example.  If you find it disconcerting like I did, then
apply the following patch before you build and install it:

20:27 [67] $ cvs diff security/ssh/Makefile
Index: security/ssh/Makefile
===================================================================
RCS file: /cvs//NetBSD/pkgsrc/security/ssh/Makefile,v
retrieving revision 1.1.1.10
diff -r1.1.1.10 Makefile
26c26
< SSH_CONF_DIR?=                /etc
---
> SSH_CONF_DIR?=                /usr/pkg/etc


NOTE:  I do *NOT* want this patch applied to the NetBSD sources!

> Perhaps you can enlighten me as to the
> advantages of seprating the configuration files for package programs
> and non-package programs.

You've already mentioned the issue of developing packages.  Another
reason I want to keep packages separate from the system so that system
upgrades don't clobber (or otherwise disturb) packages, and vice versa.
It's also more elegant and self explanitory to keep them separate.  I'm
sure there are other reasons too, but the ones listed to date are
sufficient for me.

To some extent I do also want to share /usr/pkg on diskless machines,
but in those cases I *will* make a symlink such as this if I want to
have unique configurations for any packages on any given machines:

	/usr/pkg/etc  ==>  ../../var/pkg.etc 

(Note that you really must do this if you share /usr/pkg on diskless
clients and you apply my SSH pkgsrc fix above because SSH stores the
host's private key there -- you wouldn't want all your clients to share
the same private key unless they were truely masquerading as each other,
which is why the SSH package still uses /etc by default.)

/usr/pkg/var is also a special case.  On a diskless client you would
either require two separate private partitions (/var and /usr/pkg/var),
or a symlink such as with /etc/ anyway, because you cannot, or should
not, share stuff that packages might put in a private disk partition,
such as log files, state files, etc.

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