Re: pkgsrc RC scripts

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

    Date:        Sun, 4 Oct 2009 15:11:05 +0200
    From:        Joerg Sonnenberger <joerg%britannica.bec.de@localhost>
    Message-ID:  <20091004131105.GA19781%britannica.bec.de@localhost>

  | Let's ignore the use of absurdity as rhetoric device for a moment.

OK...

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

Yes, I know - and I also appreciate the fact that in general you only see
the complaints, those of us who are happy the way it is now aren't
continually sending in "it's great, leave it alone" messages, whereas
those who would like to see it change complain all the time.  From just
what you observe, it must seem as if everyone would like to see it changed.

  | In fact, using a separate directory for local
  | additions makes a lot of sense.

I disagree - there are some places where everything just has to come
together, and this, I think, is one of them.

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

No, I didn't miss it, no question that for system upgrades, having everything
nicely separated out makes things easier - just as it would if pkgsrc
added users were in a different passwd file, etc.

But for at least most of us, upgrades are relatively rare.  Personally
I very rarely ever do one - as long as the hardware keeps on working I
just let the system remain as it is (just fix individual bugs as needed).
I put newer versions (as new installs) on new hardware, the old eventually
gets retired or dies.   But (aside from a few developers) even people who
do upgrades don't do it often.

On the other hand, day to day maintenance of daemons etc happens frequently,
and checking what is happening even more frequently, having to figure out
which of the N possible places I need to look in this time is just too
much day to day pain to tolerate.
 
  | It also helps in the not too unlikely case
  | that things moves in and out of base.

I'm not sure that it really does, I use BIND from pkgsrc (which is, I
suppose, what you mean by "move out of base") and it's really simple to
just define the command location and let it all just work.

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

That's true, but that doesn't answer the point of subverting the system
owner's desire - as we have recently seen, some people like the warnings.
If you put your line in every rc script, they have no way to ever have
the warnings they want to see.

On the other hand, the following one line change to rc.subr will allow
everyone to have just what they want ...

--- /etc/rc.subr        2004-10-12 21:45:29.000000000 +0700
+++ /var/tmp/rc.subr    2009-10-05 21:43:50.000000000 +0700
@@ -64,6 +64,7 @@
                return 1
                ;;
        *)
+               [ "$1" != WARN_RC_UNDEFINED ] && checkyesno WARN_RC_UNDEFINED &&
                warn "\$${1} is not set properly - see ${rcvar_manpage}."
                return 1
                ;;


That's from some random (3.99.x I think) version of rc.subr, so the
line numbers will be off, but I think it should apply on any rc.subr
up to and including today's current.

Sure, people who don't have this change won't be affected, but they're
probably already used to it - and what's more, if they prefer, patching
this one line into rc.subr is a pretty trivial thing to ask them to do.

I leave it for someone else to decide whether /etc/defaults/rc/conf should
have
        WARN_RC_UNDEFINED=YES
in it or not.   Once it becomes optional, the default value isn't really
all that important to most people, someone else gets to decide what is best
to ship for new users.

[Aside: the var name I picked to allow people to decide if they want the
warnings or not is most probably not a good choice - just something to
start with ... using upper case was deliberate though, to reduce the
chances of any accidental clash with a rc script variable name.]

kre