On Mon, 26 Apr 1999, Andrew Brown wrote:

# >One _could_ write a setup to handle things such as:
# >
# >	rl [ options ... (to be defined) ] {+-}state-or-stage
# >
# >which could be made to handle dependencies, i.e.
# >
# ># rl +component-a
# >* rl: component-a depends on: component-b component-c
# >** rl: component-b depends on component-d
# >*** rl: <startup message for component-d>
# >** rl: <startup message for component-b>
# >** rl: <startup message for component-c>
# >* rl: <statrtup message for component-a>
# 
# that's nice.
# 
# ># rl -component-a
# >* rl: component-a requires: component-b component-c
# >** rl: <shutting down component-b>
# >** rl: component-b requires component-d
# >*** rl: <shutdown component-d>
# >** rl: <shutting down component-c>
# >* rl: <shutdown component-a>
# 
# that's not.  that sort of "assumes" that component-b is needed *ONLY*
# for component-a.  so...hey!  if i pkg_delete xv, should i expect it to
# pkg_delete libjpeg for me?  same sort of thing.  likewise libc.  xv
# has an unstated dependency on lbc...and i don't want it removing that.

You're throwing in a red herring -- shutting down a service is not
as extreme as deleting a package.

# so if i shut down nfs which requires networking, i don't want
# networking shutdown for me.  but i also don't want nfs started up if i
# have no networking started.

I think I may have illustrated the logic incorrectly.  I meant to
show that if you shut down networking, everything which depends on
networking goes down, not vice versa :-).

# >Probably too complex and bloated, though.  I'd still prefer it to the
# >atrocity that is "runlevels" under missed-em 5.
# 
# it's a bad idea.  once you get into "incredibly finely tuned modular"
# systems like that, everyone comes up with their own "legitimate" uses
# for it that don't quite match (a) they way it comes out of the box or
# (b) the way other people use it.

Welcome to NetBSD.  No two systems owned by different people are likely
to be exactly alike.

# and then there's the dependency thing.  those scripts, if they're
# gonna work the way they purport to work, they really need to be
# idempotent.  and they never are.

I need to look that word up.

As far as the dependency "thing", think of it as a lightweight version
of "make" that goes off at boot time, with different stages established
as different targets.

				--*greywolf;
--
	If your OS and/or machine absolutely cannot autoboot without manual
	intervention, it isn't worth jack.
		-- from the notebooks of another heretic.