Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 10 Jun 2005 02:32:34 +0200
From:      Jose M Rodriguez <josemi@freebsd.jazztel.es>
To:        Doug Barton <dougb@freebsd.org>
Cc:        ports@freebsd.org
Subject:   Re: Including PREFIX/etc/rc.d/* scripts in the system's rcorder for startup in 6.0-Release
Message-ID:  <200506100232.34832.josemi@redesjm.local>
In-Reply-To: <42A8B4E6.9090401@FreeBSD.org>
References:  <42A8B4E6.9090401@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
El Jueves, 9 de Junio de 2005 23:30, escribi=F3:
> 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=20
in the RELENG_6 timeline.

=46irts, most ports in real need of rcorder can't wait to localpkg, and=20
use direct rc support breaking $prefix.

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

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

I still remember latest approach to solve this.

I think that the only safe way to take this is make some sort of 'stage'=20
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=20
rcorder for stage 'n' mixing scripts with key 'stage n'=20
in /etc/rc.d/*, /usr/local/etc/rc.d/*, /usr/X11R6/etc/rc.d/* ...

=2D-
  josemi



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200506100232.34832.josemi>