[ On Tuesday, October 22, 2002 at 19:06:33 (+0100), Jonathan Perkin wrote: ]
> Subject: RCD_SCRIPTS_DIR
>
> It maybe just because I use pkgsrc on a machine I don't have root on and

You _really_ probably should _NOT_ try using pkgsrc if you aren't
allowed to be root.  Many things cannot install properly without being
installed by root.  Obviously setuid programs won't work, nor as you've
noticed can you make use of rc.d scripts.  Pkgsrc really does need the
installs to be done as root, which is why when you run "make install" as
a non-root user it first asks you for the root password.

> run into "problems" which others don't hit, but it still strikes me as
> odd that these variables are set such:
> 
> RCD_SCRIPTS_DIR?=       /etc/rc.d
> RCD_SCRIPTS_EXAMPLEDIR?=        ${PREFIX}/etc/rc.d
> 
> Is there something which means we can't just leave pkgsrc startup
> scripts in ${PREFIX}/etc/rc.d and run them from there?

It seems nobody's answered your basic question yet -- at least not on
the list, and that's where you asked replies to be sent.

Indeed there is a reason.   The generic configuration cannot assume that
${PREFIX} is on the root filesystem, and therefore that's not a suitable
place for the scripts to be run from, by default.

There's been a great deal of discussion over this very issue in the
past, and the final decision has been that by default rc.d scripts
should be installed as examples in ${PREFIX}/etc/rc.d and that
administrators be instructed to copy those scripts into /etc/rc.d when
they wish to "enable" the package (and of course they probably still
have to set a flag variable in /etc/rc.conf to actually "turn on" the
package).

>  Not only for
> people like me who can't write to /etc

Note that if you can convince your system to run scripts or programs on
reboot that you have installed, then you can very easily obtain root
privileges on that system!  ;-)  That's a back door about as wide as the
galaxy, if not wider.

> , but also for read-only mounted /
> installs.

Huh?  That doesn't make sense.  You normally don't/can't do maintenance
on a system when the root filesystem is mounted read-only.  You can't
even effectively use some standard NetBSD features if the root
filesystem is mounted read-only.  For example nobody could ever change
their password on such a system.

Obviously the package could still be installed on a non-root filesystem
even if the root filesystem is read-only, but of course to actually
enable any rc.d script you'd have to copy the script into /etc/rc.d, and
that requires write access to /etc, which _MUST_ be on the root
filesystem (at least it must for the standard /etc/rc to work).

>  Also makes more sense in keeping pkgsrc separate to base.

No, not really, it doesn't at all.  The whole point of "packaging"
software is to carefully manage which files belong to which packages.
While there's no default integration yet with the lists of files which
belong to the main system, this isn't far in coming.  Once you know the
origin and "ownership" of each file then there's absolutely no need for
artifical separation of files from different origins into different
hierarchies and such inappropriate complication can be done away with.

> A quick search also and I don't see a /usr/pkg/etc/rc.conf equivalent.
> Worth implementing one?

No, definitely not.  All "local" startup configuration settings are in
/etc/rc.conf (and /etc/rc.conf.d/*), whether it be for packages or base
system software.

The only thing that might be worth implementing would be to install
examples for the default "${rcvar}=whatever" and
"${rcvar}_flags=whatever" values for package rc.d scripts into
${PREFIX}/etc/rc.conf.d/${name} and recommend that admins also copy
these files to /etc/rc.conf.d when they enable a package.  This way
smarter handling of defaults could be done for packages as well.

-- 
								Greg A. Woods

+1 416 218-0098;            <g.a.woods@ieee.org>;           <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>