Subject: Re: HEADS UP: RCD_SCRIPTS_EXAMPLEDIR changed to share/examples/rc.d
To: Robert Elz <email@example.com>
From: Dieter Baron <firstname.lastname@example.org>
Date: 12/28/2004 22:29:45
In article <19069.1104264294@munnari.OZ.AU> Robert wrote:
: | This sounds trivially easy to fix: make the pkgsrc-supplied scripts more
: | lenient by setting the rcvar =NO before slurping in rc.subr/rc.conf.
: Yes, initially I'd thought that would work too, but it turns out not to.
: It is possible for rc.conf to get read just once, and not once per
: script (depending upon how things are configured), in which case the
: setting in the script would override the setting in rc.conf - which is
: not exactly what is wanted.
: Or at least that's how I recall the counter argument, but even if I don't
: have it quite right, I am sure that the real argument totally convinced me
: at the time.
We have a way to test if the variable is set (as implemented in
/etc/rc.subr's checkyesno), so we can easily implement a function
isset and use that in pkgsrc rc.d scripts to set the variable.
This is a technical problem that is not hard to overcome.
: All this really was discussed before, even I, with my pathetic memory,
: remember that. The solution that (I believe) has been implemented was
: the outcome - the best that can reasonably be done, even if it isn't
: as great as you'd like it to be.
As I recall, the main argument against automatically running
pkgsrc's rc.d scripts was that people don't trust them enough not to
start servers without explicitly being told to. I would say those
rc.d scripts are buggy and should be fixed, but should not keep us
from easing the use of pkgsrc.
: | It shouldn't have to involve copying files around, one at a time, in the
: | case of binary package defaults.
: The automated way doesn't - you simply tell pkgsrc (in mk.conf) to
: install the rc.d scripts for you (and if you don't like the default
: location, where to install them), once, and forever after it does what
: you want (all but editing rc.conf for you).
Does this also work for binary packages?
: | We don't do that for base system rc.d
: | scripts; why should we require that for pkgsrc?
: That's because for the base system it is possible to ship defaults/rc.conf
: with appropriate default values in it. That can't be done for pkgsrc,
: we have no idea what will be needed.
No, the packages will have to provide these defaults, by including
them in the rc.d script, by providing a separate file with the
defaults, or by editing a common defaults file upon install/deinstall.
Or by any other means we come up with.
All these arguments sound like ``We can't handle pkgsrc rc.d scripts
exactly as we do for basesrc, so we can't handle them at all.'' rather
than the more constructive question of ``What would be needed to
handle pkgsrc rc.d scripts?'' and then move to implement that.
: | The defaults should make it as easy as possible to integrate pkgsrc packages
: | into the running system.
: I think they do. The operative words are "as possible".
``As possible without *any* change to the base system'', maybe.