Subject: Re: Proposed rc.d changes....
To: Hubert Feyrer <feyrer@rfhs8012.fh-regensburg.de>
From: Luke Mewburn <lukem@cs.rmit.edu.au>
List: tech-pkg
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
> > `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?
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 :-)