On Thu, 4 Jan 2001, Frederick Bruckman wrote:

[...]
> write all those scripts for packages. Now that I see how easy it is to
> copy an existing base script and modify it -- using the full power of
> rc.subr -- I'm all for it, but that only works if you drop them into
> /etc/rc.d, and set their variables in /etc/rc.conf (or /etc/rc.conf.d,
> or somewhere else on the / file-system). Having to write stand-alone
> rc.d scripts, so people could keep their /etc pure, sucks.

All it takes is one extra line at the top of the scipts to source
/usr/pkg/etc/rc.d as well... rc.subr doesn't depend on the control
variables being set in rc.conf.

My current xfstt reads:

#!/bin/sh
#

# PROVIDE: xfstt
# REQUIRE: DAEMON LOGIN
# BEFORE: xdm

. /usr/pkg/etc/rc.conf
. /etc/rc.subr

name="xfstt"
rcvar=$name
command="/usr/X11R6/bin/${name}"
command_args="& sleep 2"
extra_commands="reload"

load_rc_config $name
run_rc_command "$1"

...and /usr/pkg/etc/rc.conf is a mundane:

xfstt=YES               xfstt_flags=""          # X11 True Type font
server

(I'd have it sourcing /usr/pkg/etc/rc.conf if there were defaults, but
this is homebrewed rather than from pkgsrc, so there aren't)

That's one extra file (per system) and one extra line (per package
script)... what's so bad about it?

> > And you say "Here, the user edits exactly one..." as if this doesn't hold
> > for what I proposed too - just the line the user edits is in
> > /usr/pkg/etc/rc.conf instead in my version...
> 
> I read that you were proposing two versions of the rc.d script to
> serve two different set-ups. Maybe I didn't understand.

No, no, no... my script uses configuration from /usr/pkg, but some people
said that people using NFS-shared /usr/pkg (in a cluster for
example) might want per-machine configuration, so I just demonstrated that
***/usr/pkg/etc/rc.conf*** could be written to have conditional code based
on hostname, source files in /etc, etc. in that special case. The
/etc/rc.d scripts stay unchanged!

> It also seems
> that your script is not complete and working. Filling in the missing
> functionality which is found in /etc/rc.subr (choice of
> .../etc/rc.conf or .../etc/rc.conf.d/, for one) would make it a lot
> more complicated than the script I gave.

The example script I gave before was written without a nearby NetBSD box
to look up the right names of variables on :-)

The example I've copied out above is what I'm using right now on my
laptop. The rc.d scripts from packages live in /etc/rc.d, are
rcorder-marked to not be run until after /usr/pkg is mounted, and have
just one extra line added to them to pick up the configuration from
/usr/pkg/etc/rc.conf. I haven't thought about making
/usr/pkg/etc/rc.conf.d/ - I didn't know that existed until recently :-)

ABS

-- 
                               Alaric B. Snell
 http://www.alaric-snell.com/  http://RFC.net/  http://www.warhead.org.uk/
   Any sufficiently advanced technology can be emulated in software