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.

						yours,
						dillo