Subject: Re: Proposed rc.d changes....
To: Luke Mewburn <firstname.lastname@example.org>
From: Hubert Feyrer <email@example.com>
Date: 05/01/2000 18:04:34
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,
> 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
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?
NetBSD - Better for your uptime than Viagra