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