> To summarize:
>
> (1) The tools are there to give users the ability to install binary
>      packages and have the result be no different than installing fro=
m
>      pkgsrc -- simply set PKG_CONFIG and PKG_RCD_SCRIPTS as you like =
in
>      your shell environment.

OK, I admit that I was not aware of the mentioned environment
variables which might affect where things are being installed.
However, I also suspect that few other newbie or relatively
experienced users were aware of these, so the usability argument still
holds -- it should not be necessary to be a pkgsrc expert (i.e. know
about these variables and what they do) in order for a binary package
to install rc.d and configuration files in the right place for the
services of the package to be activateable without additional manual
steps up and above the usual "edit rc.conf to enable rc.d script"
step.

This is more about "reasonable defaults", than "yes, it is possible to
get the behaviour you (presumably) desire."

> (2) The history behind the current default of PKG_RCD_SCRIPTS=3DNO is=
 such
>      that no extra services are started at boot without the
>      administrator's explicit consent at some point, either by direct=
ly
>      copying the script into place, or by setting PKG_RCD_SCRIPTS=3DY=
ES and
>      PKG_CONFIG=3DYES.  This ensures that, by default, you are safe f=
rom
>      remote exploits in the packages that you install.  This is why r=
c.d
>      scripts are not simply another kind of CONF_FILES.
>
> Changing the default to PKG_RCD_SCRIPTS=3DYES would require sweeping
> through pkgsrc to fix up the scripts to be safe to install by default=
,
> and also require a procedure to try to ensure that new packages as
> well as changes to existing packages will not install unsafe scripts.=


Well, yes, I'll agree to some of this...

Earlier in the discussion it has been mentioned an existence proof of
a problem with a package whose rc.d script would perform the "start"
function even in the absence of an appropriate function=3DYES setting i=
n
rc.conf.  Obviously such startup scripts are buggy, and as such needs
to be fixed.

Yes, a sweep of the packages which install rc.d script would be
useful.

> I think that this is simply a hard problem, and that it's not a big d=
eal
> to push the responsibility to the local sysadmin.

My personal opinion is that we are not gaining much by ignoring the
problem and "solve" it by putting "new and exciting" stumbling blocks
in the way for new users making it extra difficult (either by
requiring unintuitive manual steps to be performed or by having to
know about these additional variables which have to be set in order to
get behaviour as expected when coming from other similar systems) to
get the services offered by the packages started.

Even though we do the adaptation of third-party software to NetBSD
(and other systems) via pkgsrc, we can't really take full
responsibility for any bugs or security problems in these third-party
packages.  I have the impression we do a reasonably responsible job
already, via the audit-packages package and the maintenance of the
pkg-vulnerabilities file, and associated updates (although the branch
maintenance could flow a little more smoothly...)

Regards,

- H=E5vard