Re: pkgsrc RC scripts

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    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 ...

Absurd?  Yes, of course it is, but it all starts from the decision to
add a second script directory.   One is enough, there's no rational
reason to want to "keep a logical separation" - we don't do that in other
places, if pkgsrc wants to add a new user, the user name goes in /etc/passwd
(and /etc/master.passwd of course), not in /etc/pkgsrc-passwd or something
(with corresponding additions to the rest of the system so it can deal with
two password files).   We could do that to "keep a logical separation"
between users that are part of the base system, and others added by pkgsrc
(and then create yet another password for file locally added users, like me)
but I don't see anyone suggesting that as the path to adopt (and a good thing
that they're not).  "Logical separation" for rc scripts is just as
meaningless.

If it looks like it simplifies things for users, that's mistaken, it just
means that (unless we proceed down the above absurd path) I now have a
decision to make when I install something outside pkgsrc (which many of us
do, occasionally), should I put my application's startup script in with the
base system scripts, or in with the pkgsrc scripts?  It is neither, but
it has to go somewhere.   As things are now, things are simple, there's
just a directory of startup scripts, it belongs to no-one, and everything
goes there.  Simple, and clean.

  | (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.

After all, all the base system scripts have (or should have) their
control variables in /etc/defaults/rc.conf so the test can really only be for
add on scripts, which is mostly pkgsrc added scripts, if pkgsrc then
defeats that by always defining the variables, the test has no purpose
left, and may as well be rmeoved.

Further, as a solution this prevents pkgsrc from subverting the base
system guidelines for how rc scripts should be installed - if the base system
(be it NetBSD or something else) really wants people to have to explicitly
set the control variable (one way or the other) when a script is installed,
perhaps in order to show people how to enable the thing, pkgsrc shouldn't
really be subverting that.

kre