Including PREFIX/etc/rc.d/* scripts in the system's rcorder for
startup in 6.0-Release
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.
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
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