># (1) echo LOCALBASE=/usr/pkg >> /etc/rc.conf
># (2) echo 'command=$LOCALBASE/bin/ntpd' > /etc/rc.conf.d/ntpd
>#
># ...and you're done.  no?
>#
>
>rc.conf.*d*?  We're making a whole bloody tree specifically for rc.conf
>stuff?

well...

    % pwd
    /usr/src/etc
    % cvs annotate rc.subr |grep rc.conf.d
    Annotations for rc.subr
    ***************
    1.20  (fvdl  09-Jun-00): 	if [ -f /etc/rc.conf.d/"$_command" ]; then
    1.20  (fvdl  09-Jun-00): 		. /etc/rc.conf.d/"$_command"

its been there for a while, so i wouldn't say making.  i'd say we've
just found another good use for an existing tool.

>Oy.  That's just about hitting the height of absurdity.  I find this
>solution to be ludicrous.  How far are we going to split things out,
>here?  With the way things are sharding, I'm inclined to say that we're
>starting to make Debian look easy.

well...let's see.  unlike in 1.3.x and prior, /etc/rc should not need
to be modified by the end user at all (indeed, before 1.3, there was
no rc.conf, so tweaking the way things ran was easy enough, but
upgrades were a royal pain).  /etc/rc.d might be, but with this
particular application of something that you didn't know about, i'd
say that need is pretty much obviated as well.

don't get me wrong, if you're dead set on modifiying the /etc/rc.d
scripts and handling upgrading them by hand, that's fine with me.  :)

-- 
|-----< "CODE WARRIOR" >-----|
codewarrior@daemon.org             * "ah!  i see you have the internet
twofsonet@graffiti.com (Andrew Brown)                that goes *ping*!"
andrew@crossbar.com       * "information is power -- share the wealth."