On Mon, 1 May 2000, Luke Mewburn wrote:
> 4. Supporting pkgsrc rc.d scripts
> 
> 	I suggest that the pkgsrc system is setup such that we supply
> 	and install rc.d scripts that are written to work as our
> 	system scripts do, in that:
> 		* our configuration mechanism is used
> 		* the rc.subr helper functions are used
> 		* appropriate PROVIDE/REQUIRE dependancy elements are set

This needs more details. 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.


> 	Also, by default, the package should setup things such that
> 	the program is started by default, since this is the principle
> 	of least surprise (and effort :-) for the majority of our
> 	users. Of course, I suggest that we add support to install
> 	it disabled with something like an mk.conf variable such as
> 	`PKGSRC_RC_D_DEFAULT_DISABLE' being set.

How do you think this should be handled inside the pkg system? Make a
variable (RCSCRIPT?) that contains the rc-script's final place (e.g.
share/examples/rc.d/foopkg) and that's copied to /etc/rc.d from
the post-install target (or later?) if PKGSRC_RC_D_DEFAULT_DISABLE is
not set?

Also, the same mechanism must be available for binary packages. Any ideas?
@rcscript directive in the PLIST (maybe generated automatically when
RCSCRIPT is set), that is copied to /etc/rc.d if some switch is not set?
And pkg_add/info/delete handling this properly?


 - Hubert

-- 
NetBSD - Better for your uptime than Viagra