Should etc/rc.d/ike move to ports?
Ion-Mihai Tetcu
itetcu at people.tecnik93.com
Fri Dec 16 18:04:07 PST 2005
On Fri, 16 Dec 2005 17:51:16 -0800
Doug Barton <dougb at FreeBSD.org> wrote:
> Ion-Mihai Tetcu wrote:
> > On Fri, 16 Dec 2005 17:39:27 -0800
> > Doug Barton <dougb at FreeBSD.org> wrote:
> >
> >> Ion-Mihai Tetcu wrote:
> >>
> >>> Better use:
> >>> USE_RC_SUBR= ike
> >>> and put the script in files/ike.in
> >>>
> >>> Currently this will perform some substitutions on the script
> >>> (PREFEIX, etc.) and install it as ike.sh
> >> Thanks for that, I wasn't aware that a .in vs. .sh.in was already
> >> working :)
> >
> > Now:
> > USE_RC_SUBR= name.sh.in --> name.sh
> > USE_RC_SUBR= name.in --> name.sh
> > Then:
> > USE_RC_SUBR= name.sh.in --> name.sh
> > USE_RC_SUBR= name.in --> name
> >
> > Is this not what we want ?
>
> For the Now part, yes. For the Then part, the important factor is
> whether the system is past the local_startup MFC or not. If not, then
> we always want to install as name.sh, otherwise the script won't run.
> If so, then we want to install as just name. There is also the factor
> of how to deal with a port that has a legitimate need to install as
> name.sh in the post MFC world, which would mean (after all the ports
> are fixed) that its boot script gets sourced into the rc environment,
> rather than run in a subshell. I'd organize Then like this:
>
> Pre-MFC system:
> USE_RC_SUBR= * --> name.sh
> Post-MFC system:
> USE_RC_SUBR= name.in --> name (this will be the common case)
> USE_RC_SUBR= name.sh.in --> name.sh
>
> Make sense?
Yes, that's what I (wanted to) say. ("my" then = post-MFC, post-fix_ports).
Pav's PR will get us support for this in bsd.port.mk, the rest is
fixing the ports to be rc.d compatible and repo-copies.
--
IOnut - Unregistered ;) FreeBSD "user"
"Intellectual Property" is nowhere near as valuable as "Intellect"
Mail server hit by UniSpammer
More information about the freebsd-rc
mailing list