Subject: Re: HEADS UP: RCD_SCRIPTS_EXAMPLEDIR changed to share/examples/rc.d
To: Todd Vierling <firstname.lastname@example.org>
From: Johnny C. Lam <jlam@NetBSD.org>
Date: 12/30/2004 09:32:36
Todd Vierling wrote:
> On Wed, 29 Dec 2004, Johnny C. Lam wrote:
>>> o There is no good reason that I can see that a default installation
>>> from (pkg)source and a default installation from a binary package
>>> should result in a different result.
>>PKG_CREATE_USERGROUP, PKG_CONFIG, and PKG_RCD_SCRIPTS are not only settable in
>>/etc/mk.conf, they are settable in the shell environment. This means if you
>>set PKG_CONFIG=yes and PKG_RCD_SCRIPTS=yes and then run:
> So why does PKG_RCD_SCRIPTS default to "no"? Binary packages should be
> doing as much as possible to ease installation in the default case (which is
> a restatement of Havard's restatement of what I said earlier :).
> Again, I see no reason it should be possible to disable copying rc.d scripts
> unless you're also wanting to disable CONF_FILES and friends at the same
> time. rc.d scripts, in my view, are just another kind of CONF_FILES.
(1) The tools are there to give users the ability to install binary
packages and have the result be no different than installing from
pkgsrc -- simply set PKG_CONFIG and PKG_RCD_SCRIPTS as you like in
your shell environment.
(2) The history behind the current default of PKG_RCD_SCRIPTS=NO is such
that no extra services are started at boot without the
administrator's explicit consent at some point, either by directly
copying the script into place, or by setting PKG_RCD_SCRIPTS=YES and
PKG_CONFIG=YES. This ensures that, by default, you are safe from
remote exploits in the packages that you install. This is why rc.d
scripts are not simply another kind of CONF_FILES.
Changing the default to PKG_RCD_SCRIPTS=YES 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.
I think that this is simply a hard problem, and that it's not a big deal
to push the responsibility to the local sysadmin.
-- Johnny Lam <jlam@NetBSD.org>