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

Greg, I have no idea if you are deliberatly trying to post inflamatory
comments, or if you are
just caught up in the excitement of ideas that have been bouncing around for
the last day, but
I suggest that you take a good long look at what you just wrote. I believe
that the "charade"
of trying to isolate "third-party software" was done for good reasons. 

I am (of course) not all knowing and seeing so please educate me if you feel
I am ignorant, but here is my datapoint. I do not want to have third party
config files in /etc. EVER.
I am running on less than new architechtures and if you put third party
config files in
/etc, it will require even LONGER to reboot when I've got a problem, and
reinstall will
become a nightmare. I had understood that some of this discussion was
directed at keeping
some form of rc.conf at least buildable by the people who want it, and I am
wondering if 
some of the wonderful new ideas of how to deal with rc.d* will abrogate
that. I personally
don't have the experience to decide that, but I would ask that you (the
group of people
that are disscussing it on this newsgroup)keep that in mind.

>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!  ;-)

I am not convinced. This sounds an awful lot like what Micro$oft was trying
to do.
Forgive me for bringing evil into the discussion.

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

Part of the
charm of NetBSD was that it supports hardware and configurations that no one
else in
their right mind would even concieve of supporting anymore. But for
educational 
institutions and people like me who don't have the money for latest and
greatest toys,
and we have to deal with whatever we are given, NetBSD is a life saver,
right now anyway.
Please also keep that in mind. Some of the things that are proposed sound
like they
will make NetBSD much more attractive to the mainstream niche. What about
the rest
of us?

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

I would also like to note that there is a possibility that I am going to be
the only
one to post to this thread in this manner , since people of my bent were
told by Luke 
that any form of"re-hashing" would be summarily deleted. I realize why he
did this, but 
because he did so, the only people who have so far posted are pro-rc.d*, and
likely it will 
remain this way because pro-rc.conf have been told they cannot offer
opinions. I know that this
is an extreme interpretation of what Luke said. Luke actually said something
like
'Please post constructive critisism, and not flame" but I'm afraid that
because of
the way he said it, there will be no critisism at all from that corner,
which means that
and entire segment of the NetBSD user population is silencing itself. I am
concerned about
this because when a small group of people who are all enthusiastic about a
particular
concept get together, they tend to brainstorm with each other, and not offer
viewpoints
that people who are skeptical might. I am not questioning your ethics, it's
just one of
those polarity things that happens in committies. But I am concerned, and if
anyone has
a way to re-involve people in the disscussion, I think it would be a good
idea.

Hope this doesn't throw too much sand on your enthusiasm, I really do
appreciate the time
and effort you spend on things. I know I've said it before, but I'm going to
keep
saying it because I feel it needs to be said.

Carrie Jones