Subject: Re: Proposed rc.d changes....
To: None <tech-userlevel@netbsd.org, tech-pkg@netbsd.org>
From: Greg A. Woods <woods@weird.com>
List: tech-userlevel
Date: 05/01/2000 20:43:30
[ On Tuesday, May 2, 2000 at 08:34:52 (+1000), Luke Mewburn wrote: ]
> Subject: Re: Proposed rc.d changes.... 
>
> Hubert Feyrer writes:
> >
> > How about we ship a pkg's rc.d script in (say)
> > share/examples/rc.d/foopkg, and the copy it to /etc/rc.d in a
> > post-install/@exec line? The latter could maybe even be added to the
> > PLIST automatically, see below. We'll have to agree on a common way to
> > do this, though.
> 
> 	I'm not exactly sure the best way to implement this in the
> 	package system.
> 
> 	From a functionality point of view, I think that the rc.d
> 	script should be copied to /etc/rc.d at some stage of `make
> 	install', as long as the file doesn't already exist. If it
> 	does exist, bitch a lot. If we go separate configs per file
> 	similar rules for the config file should apply.

There is no "make install" in the package system proper.  There are
"REQ" (hopefully renamed to "REQUIRE" someday) and "INSTALL" scripts
though.
 
Personally I'd like to see a command-line option to pkg_add, which could
optionally be set via an environment variable, that would cause a
package to be "enabled" upon install.  This "enable" action would mean
installing any default configuration files in their expected places as
well as creating the hard link from any the init.d script(s) to the rc.d
directory.  For those people who install stuff directly from pkgsrc and
expect it to be enabled right away there could be a variable setting in
pkgsrc/mk/mk.conf(.example) that enables this feature during the
registration phase.

Please also, no "copying", and no symlinks either.  Create hard links
from (/usr/pkg)/etc/init.d to (/usr/pkg)/etc/rc.d to enable a script.
The hard link makes it possible to infer by a simple "ls -l" what's not
turned on yet, and also make it possible to see if anyone accidentally
renamed a script (i.e. the inode numbers will be the same), and most
importantly of all they make it impossible (well "much harder") for
changes to be lost because someone edits the wrong copy.  These are all
lessons learned from 10 years of running AT&T SysV machines.

> 	Now, if the best way to impleement this is to first put the
> 	script into /usr/pkg/etc/rc.d, and then copy it postinstall
> 	if the /etc/rc.d/foo doesn't exist, then that's fine by me.
> 	I suppose that has the benefit that you always have a copy of
> 	the `virgin' script around too...

Please, let's keep package stuff *entirely* in /usr/pkg if we're going
to do things that way.  I.e. drop scripts in /usr/pkg/etc/init.d and
turn them on by creating a *hard* link to /usr/pkg/etc/rc.d.  It's
trivial to run "rcorder /etc/rc.d /usr/pkg/etc/rc.d ..." and still be
able to "mix" system and pkg stuff together in the "right" order.  In
fact I would *strongly* suggest that an rc.conf (or whatever it ends up
being called) variable be used to specify the list of optional
directories to add to the one standard system directory to be passed to
rcorder as I show.

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>