Subject: Re: HEADS UP: RCD_SCRIPTS_EXAMPLEDIR changed to share/examples/rc.d
To: Robert Elz <kre@munnari.OZ.AU>
From: Dieter Baron <>
List: tech-pkg
Date: 01/03/2005 23:17:14
On Tue, Jan 04, 2005 at 02:20:41AM +0700, Robert Elz wrote:
> Mostly here I haven't been giving my opinions at all, I've just been
> asking questions.   That's to make sure that everything is being
> considered, and done for good reasons.
> What I said (asked) was how you explain to people why installing one
> package from pkgsrc (src or bin) just works, and another doesn't, and
> how you can justify that.

  What do you mean by ``just works'' and ``doesn't''?  If you mean,
why are servers not started by default but applications can be run
without further configuration, then I (and others) have given answers
in those responses you chose to ignore.

>   | What would be the advantage of handling pkgsrc servers differently than
>   | base system servers?
> I didn't say that they needed to be different.   In fact, we could
> consider de-populating /etc/rc.d - most of what is in there is never
> used my most of the users, it just wastes startup time determining
> that the relevant thing isn't turned on.   At the minute though, that
> directory serves double purpose, it is both the home of the scripts that
> are needed at startup, and the storage container for those that aren't,
> but might be one day.   We could move the storage container to /usr/share/
> examples/rc.d and put far fewer scripts into /etc/rc.d by default
> (just those essential for the system to operate correctly).
> Then (tool or no tool) we'd have base system / pkgsrc consistency, and
> have met your goal, in both of them you'd need to copy the rc.d script
> from the examples directory to /etc/rc.d and then enable it.

  I explained in quite some detail that I wanted enabling servers from
pkgsrc to get less complicated.  What makes you think I would like to
get enabling servers from the base system more complicated?  Just
because I didn't reiterate it in my last mail?

>   | For the kind of tools you propose, the details of how servers are
>   | enabled and configured are hidden from the admin by the tool.  So why
>   | do you argue against handling them the same way as is done in the base
>   | system (which would simplify such a tool)?
> I never argued anything like that.

  Well, are you opposed to rc.d scripts being installed somewhere
where the rc subsystem will pick them up and start the servers if they
are enabled via rc.conf?  If so, why?