Including PREFIX/etc/rc.d/* scripts in the system's rcorder for startup in 6.0-Release

Florent Thoumie flz at
Fri Jun 10 08:05:30 GMT 2005

On Jun 9, 2005, at 11:30 PM, Doug Barton wrote:

> Howdy,
> I realize that this is pretty short notice before the release, but  
> the rc.d
> team just got a spiffy new volunteer to do the legwork on this, and  
> so we're
> going to try to beat the code freeze/slushie deadline for 6.0. What  
> we've
> been discussing for the last few days on the freebsd-rc list is a  
> two-fold
> approach in order to avoid needing a flag day to cover this issue.
> The first part of the approach is to hack /etc/rc.d/localpkg to use  
> rcorder
> to handle the keywords that are already in the scripts with *.sh  
> filename
> patterns. This will preserve the lexical ordering that exists now,  
> while
> giving port authors (and users of course) the ability to start using
> keywords with existing scripts that fit the *.sh pattern.
> Part two of this proposal is to hack on /etc/rc to use rcorder on any
> scripts in PREFIX/etc/rc.d that DON'T use the *.sh filename  
> pattern, but DO
> include a new keyword (that will be specified). In this way, port  
> authors
> and users can start opting into the new system at their  
> convenience. Once
> the new system has been in place "long enough," we can drop  
> processing for
> the special key word, and just handle all rc.d scripts the same,  
> regardless
> of their location.

     That's nothing new, eik was already working on this some
     months ago. That still remains a good idea.

> This may sound more complicated than it needs to be, but the  
> discussion on
> the freebsd-rc list brought up a lot of interesting cases that need  
> to be
> considered as part of this transition, and I believe we've  
> simplified it as
> much as possible. My question at this point is, does this approach  
> sound
> reasonable? Our intention is to coordinate this closely with y'all  
> so that
> we don't do something that will break the new release, or more  
> importantly
> break backwards computability.

     Well, code slush is today, release won't happen until things
     are fixed btw. That means fixing to alter
     USE_RC_SUBR and USE_RCORDER to fit this new model, it won't
     take long. The only thing that could break are bogus rcNG
     scripts with bad PROVIDES/REQUIRES statements.

Florent Thoumie
flz at

More information about the freebsd-ports mailing list