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

Brooks Davis brooks at one-eyed-alien.net
Fri Jun 10 03:56:50 GMT 2005


On Fri, Jun 10, 2005 at 02:32:34AM +0200, Jose M Rodriguez wrote:
> El Jueves, 9 de Junio de 2005 23:30, escribió:
> > 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.
> >
> > 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.
> 
> I'm not sure that this is the correct approach.  And even maybe too late 
> in the RELENG_6 timeline.
> 
> Firts, most ports in real need of rcorder can't wait to localpkg, and 
> use direct rc support breaking $prefix.

This is easy to fix.  We just modify RC_ORDER to take appropriate action
based on the version of FreeBSD.  There's plenty of time prior to
6.0-RELEASE for that.

> Second, I can easy work scenarios where I can break any logic trying to 
> mix localpkg lex order and rcorder key order.

The fact that you can break the schem does not imply it would actually
be broken.  More importantly, a little breaking isn't all that serious.

> If we go to maintain short release cycles, please, delay this to HEAD 
> after RELENG_6.  And only merge it if we go to a safe status before 
> real release.

The problem is that we have to start some day and we won't be able to
make a full switch for at least two relases after the initial commit.
At the very least, I think we should make some attempt at supporting
rcorder orders scripts within PREFIX/etc/rc.d in 6.0.

> I still remember latest approach to solve this.
> 
> I think that the only safe way to take this is make some sort of 'stage' 
> concept into rc (use the SystemV runlevels as a very loose reference).
> 
> We can use 'stage keys' for implement this.
> 
> If we have safe localfs access at the end of stage 'n-1', we can do and 
> rcorder for stage 'n' mixing scripts with key 'stage n' 
> in /etc/rc.d/*, /usr/local/etc/rc.d/*, /usr/X11R6/etc/rc.d/* ...

This requires too much modification of scripts.  There is a quite nice
proposal on rc@ that simply requires the addition of one script to mark
the point at which scripts are rescanned.

-- Brooks

-- 
Any statement of the form "X is the one, true Y" is FALSE.
PGP fingerprint 655D 519C 26A7 82E7 2529  9BF0 5D8E 8BE9 F238 1AD4
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-ports/attachments/20050609/d3090133/attachment.bin


More information about the freebsd-ports mailing list