Re: pkgsrc RC scripts

[Joerg Sonnenberger <joerg%britannica.bec.de@localhost>]

On Sun, Oct 04, 2009 at 07:56:52PM +0700, Robert Elz wrote:
>     Date:        Sat, 3 Oct 2009 23:48:11 +0200
>     From:        Joerg Sonnenberger <joerg%britannica.bec.de@localhost>
>     Message-ID:  <20091003214811.GA20410%britannica.bec.de@localhost>
> 
>   | (1) Install pkgsrc RC scripts by default into /etc/rc.pkg.d, not
>   | /etc/rc.d and adjust the default value for rc_directories accordingly.
>   | This keeps the logical separation between base and pkgsrc RC scripts
> 
> That's not a desirable goal.  One directory of rc scripts makes sense,
> multiple directories of rc scripts just leads to even more directories of
> rc scripts, so as to "keep logical separation" - if pkgsrc has its own,
> perhaps X needs one for its scripts, and certainly my local (non pkgsrc)
> additions need yet another, and perhaps we should have the networking
> startup kept separate from the rest of the system, and put its scripts
> in a different directory - no, make that two different directories, so we
> can separate out ipv4 and ipv6 startup ... and then we'd better have more
> for appletalk, and netiso, and ...

Let's ignore the use of absurdity as rhetoric device for a moment.
One of the often voiced complains about installing the scripts
automatically is that it is hard to distinguish between components from
base and from pkgsrc. In fact, using a separate directory for local
additions makes a lot of sense. The main point you seemed to have missed
is that mixing different management domains is not necessarily a good
idea. /etc/rc.d is normally managed by postinstall. The pkgsrc RC
scripts by pkgsrc. The local additions by yourself. A clean separation
makes the process easier. It also helps in the not too unlikely case
that things moves in and out of base. It doesn't answer the problem of
having multiple RC scripts with the same base functionality, but it is a
step towards being able to resolve that.

>   | (2) Provide a default value of NO for the control variables. This
>   | ensures that no stupid "Missing variable $foo" clutters up the boot
>   | messages.
> 
> This half is entirely reasonable, but the implementation method you
> suggested in a later message is the wrong way to go about it.   I know
> you work (mostly) on pkgsrc, and so the natural thing to do is to fix
> everything in pkgsrc, and only there, and if that was a constraint, then
> your suggested fix method would work - but there's no reason to confine
> the solution there.
> 
> Just fix the rc system to stop bitching about undefined control variables
> and assume "NO" instead.   A trivial change to rc.subr and no need to
> clutter all the scripts with meaningless extra noise just to make sure
> the variable is always set.

Changing rc.subr won't help on any system already released. The trivial
one line change to the RC scripts is self-contained.

Joerg