On Fri, 17 Mar 2000, Todd Whitesel wrote:

# > Sanity check time.  As I said above, my monolithic rc file is 473
# > lines.  rc.subr *alone* is 483.
# > 
# > In short, however (un)complicated you may find it, it's a hell of a lot
# > more complicated than what we had before.
# 
# It also *does* more. A lot more. So it is not unreasonable for it to
# be bigger, or more complicated.

The point I think der Mouse is making is that it does more, sure, but
for whom?   For him (and several others I've seen, such as myself),
/etc/rc.d, at least for the stock system startup, actually gets in the
way and makes more work.

# I suppose you could make a case that it is now *bloated*. That's something
# I can't speak to (I stopped tracking -current to do 1.4.2 release builds).

There's a good argument right there.  It's become probably unnecessarily
bloated.  Isn't this something that NetBSD has historically avoided?

# > You have managed to so completely miss the point of my wanting a
# > monolithic script that I wonder if it's even worth attempting to
# > explain it again.
# 
# This wasn't aimed at me, but it makes me think: Mouse, has it ever occurred
# to you that _you_ are also being pretty damn stubborn here?? Other people
# obviously want the new functionality, but you don't seem to be giving it
# any credit at all. If you're assuming no one needs the new features just
# because you don't need them, then that's a local assumption and it instantly
# turns much of what you say here into opinions not marked as such.

...and, again, other people _don't_ want it.  We never truly reached
an acceptable solution, yet something was built and shoehorned in amid
MUCH objection.

I didn't think NetBSD was like that.  We're technical people, here,
not just some knee-jerk user group.  I don't think the objections
would have arisen if not for some technical problems.

# The reason that it is simple and straightforward is because it only does
# one thing: start everything. It does not restart, it does not stop. It
# does not manage dependencies nor does it provide for correct insertion
# of 3rd party services.

But it _could_ provide for that.  Tagged RC lines come to mind.
A script to insert stuff just-after-X or just-before-Y could be designed.

# I think rcorder needs official diagnostic options so we can get it to tell
# us what the heck it plans to do. It should be possible to get rcorder
# to generate a "flat" script that properly represents a classic rc file,
# but it would also be able to do this for shutdown as well as startup.

i.e. generate rc and rc.shutdown.  Great.  Can it regenerate the 669
lines used, or is it going to generate a 3K-line startup script and a 3K-line
shutdown script.

# Better, the rc.d stuff should be capable of acting as the build system
# for /etc/rc. This would especially be handy for debugging purposes.

This is not the point.  The point is that /etc/rc should not have been
will-ye-nill-ye replaced as was done (nor with the attitude put forth!
"Monolithic rc is going away.  Deal.").

# At the very least, it sounds like two modes, new-style and monolithic+pkgsrc,
# would be needed to satisfy everyone who's piped up so far. Shouldn't be too
# hard to get sysinst to set them both up, but of course we'd better document
# how to do this (after the section where we tell them how to run MAKEDEV...
# now where was that in the manual?).

in /etc/rc:

	if [ -d /etc/rc.d ]; then
		status=do-whatever-you-need-to-do-with-rc.d
		exit $status
	fi

Hey, wow, look, a four-line fix (modulo the do-whatever-you-need-to-do-
with-rc.d script/function).

				--*greywolf;
--
"Windows/NT - From the people who brought you EDLIN".