[ On Tuesday, May 2, 2000 at 04:44:54 (+0200), Hubert Feyrer wrote: ]
> Subject: Re: Proposed rc.d changes....
>
> >   - look for a list of optional directories where rc.d-style scripts can
> >     be found (eg. /usr/pkg/etc/rc.d, /usr/local/etc/rc.d, etc.).  For
> >     example with "more_rc_d=/usr/pkg/etc/rc.d" in /etc/rc.conf, do this
> >     in /etc/rc:
> 
> FYI, the fundamental problem seems to be there that you have to run
> rcorder *before* anything else - including the script that mounts /usr.

oops -- damn -- forgot about that.... (since I don't mount /usr  ;-)

Well, if you examine the way the average SysV-derrivative machine starts
out (eg. Sun Solaris 2.6) you'll note that the first thing it does is to
mount all local filesystems:

	#       Mount file systems
	cd /
	/sbin/mountall -l

You'll also note that it does place everything to do with system startup
in /etc (i.e. not in /opt/etc ;-), presumably under the assumption that
everything's either on the root filesystem, or on some other local
filesystem (note that the root filesystem could be on NFS for a diskless
client, but that would be rather silly).

What I would like to suggest is that NetBSD too must give up on this
charade of trying to isolate "third-party" stuff into completely
separate hierarchies.  I.e. "we" must learn that *everything* related to
system configuration *must* be in /etc and that any filesystems where
applications are started at boot time *must* be listed as "critical".

Trying to keep third-party files separate from so-called "OS-vendor"
files (for whatever misguided reason :-), means paying the cost of
ensuring everything necessary for system startup is on "local"
filesystems that can be mounted very early in the system boot process.
You cannot have your cake and eat it too!  ;-)  It also means running
two separate loops in /etc/rc to start add-on stuff and that means *not*
being able to interleave any add-on stuff in any way where it might be
able to "provide" something normally provided by a system package, at
least not without either doing some hacking or actually replacing the
system stuff outright.

In an ideal world I would want the process of "package-ing" the system
be accelerated so that third-party packages could be installed in the
base system (i.e. PREFIX=/usr, except for /etc and /var) by default,
thus avoiding this issue in the first place.  In the end this simplifies
lots of things outside of the system startup process and makes life
infinitely simpler for users too boot!  ;-)


Otherwise I think the only solution that keeps /usr/pkg/etc (and
/usr/local/etc) would be to say that configurations where a traditional
root filesystem (i.e. one where /usr is a separately mounted filesystem)
and where /usr is a remote filesystem be officially deprecated and
unsupported.  Yes I do currently boot a diskless workstation where /usr
is on a separate, shared, mount, but I could very easily avoid that by
simply doing a loopback mount of the /usr directory on the server and so
can everyone else who uses a sane platform as the file server....  ;-)
(well actually I'd have to move /usr/export to /var/export or some such
first, but you get the idea I'm sure....)

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