Subject: Re: Proposed rc.d changes....
To: Hubert Feyrer <>
From: Luke Mewburn <>
List: tech-userlevel
Date: 05/02/2000 08:34:52
Hubert Feyrer writes:
> 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.

	Yes, that's why I started a discussion on it ;-)

> 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.

	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...

> > 	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
> 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?

	I'm not sure exactly how to do it; you're the package gurus ;-)
	I was trying to highlight the functionality, which I had
	determined by talking to a few people about various
	requirements. E.g, some people wrote that they didn't want a
	package on by default because they built packages, but a lot
	of people have also expressed the desire to make things easier
	for users who expect to be able to
		* extract pkgsrc
		* cd www/apache
		* make install
	and have it just work by starting up at next boot.

More food for thought :-)