[ On Thursday, April 18, 2002 at 00:05:34 (+1000), Luke Mewburn wrote: ]
> Subject: post-installation and rc.d enhancements
>
> After careful consideration, the following solution is proposed.
> 
> 	+ All rc.d scripts will be in one directory - "/etc/rc.d"
> 
> 	+ Base system configuration comes from "/etc/rc.conf"
> 	  (and any other files sourced by that file)
> 
> 	+ Per application configuration comes from "/etc/rc.conf.d/$name",
> 	  where $name is the argument that the script calls
> 	  load_rc_config() with.

What happens to /etc/defaults/rc.conf?

> 	+ NetBSD base system rc.d scripts:
> 		- Filename, PROVIDE, and $name must not start with
> 		  "pkg_" or "local_"
> 
> 	+ NetBSD pkg rc.d scripts:
> 		- Filename, PROVIDE, and $name must start with "pkg_"

I really like being able to re-install BIND over top of the system
binaries by building it with LOCALBASE=/usr.

However I don't know what to think about the possibility someone might
actually want to have a pkg daemon installed in parallel with the same
name as a base system daemon and perhaps even run them both at the same
time....  I guess we really do need some kind of convention to separate
the namespace in order to handle this contingency.

However I would REALLY like to avoid having the namespace separation
being achieved through attaching some some magic meaning to a prefix (or
suffix) on the script file basename itself.  Because that's all your
proposal does (as it stands), there's no way to accomodate the obvious
next level of having two separate LOCALBASE settings (each with their
own PKG_DBDIR of course) and having two different versions of a program
installed under the same name, but in different hierarchies, perhaps in
addition to an original base system version too.  I've already
experimented with this scheme (mostly successfully) with the intent of
finding a way to build and install test versions of packages on the very
same machine where they're running in production (and must stay running
in production during the tests).

I still think the best solution is to just install pkg rc.d scripts in
$PREFIX/etc/rc.d and to support chaining to other rc scripts by default
-- i.e. run (each) $PREFIX/etc/rc at the end of /etc/rc, or maybe even
as a separate /etc/rc.d script (one per $PREFIX) that would normally run
very near the end, if not the very end.

For those of us who need/want to sometimes mix (and/override) pkg stuff
with base system stuff we can either make $PREFIX/etc a symlink to /etc,
or we can install with LOCALBASE=/usr (and make /usr/etc a symlink to
/etc and of course make sure /usr is on the root filesystem :-), or we
could even put $PREFIX on the root filesystem and simply process all the
$PREFIX/etc/rc.d scripts with the very same rcorder run as the base
scripts (and of course make sure rcorder does the right thing with
respect to handling multiple scripts with the same name and the same
PROVIDE token).  I've successfully used all three of these options
(except for testing that very last caveat).

> 		- Script must  "REQUIRE: mountcritremote"
> 		  (as /usr might be a remote file system).
> 		  Other dummy dependencies (c.f. rc.d(8)) such as
> 		  NETWORKING, SERVERS, DAEMON or LOGIN can be REQUIREd
> 		  as necessary.
> 		- /etc/rc.conf.d/pkg_*  can be used for configuration.

Ideally the package would add its own per-pkg, non-user-editable,
original default configuration parameters file in $PREFIX/etc/defaults/
(or some sub-directory).

That way admins could continue to use /etc/rc.conf for localised package
tweaks.

(I personally don't forsee any need to have to use /etc/rc.conf.d/* on
my systems and I'd like to keep it 100% empty if possible.  If that's
going to be where sushi mucks about then it should probably be
explicitly reserved as sushi-only territory.)

-- 
								Greg A. Woods

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