From owner-freebsd-ports@FreeBSD.ORG Fri Jun 10 00:32:39 2005 Return-Path: X-Original-To: ports@freebsd.org Delivered-To: freebsd-ports@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5443716A41C; Fri, 10 Jun 2005 00:32:39 +0000 (GMT) (envelope-from josemi@freebsd.jazztel.es) Received: from 62-15-207-140.inversas.jazztel.es (62-15-207-140.inversas.jazztel.es [62.15.207.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id 98D6343D48; Fri, 10 Jun 2005 00:32:37 +0000 (GMT) (envelope-from josemi@freebsd.jazztel.es) Received: from redesjm.local (orion.redesjm.local [192.168.254.16]) by 62-15-207-140.inversas.jazztel.es (8.13.3/8.13.3) with ESMTP id j5A0WZbd002360; Fri, 10 Jun 2005 02:32:35 +0200 (CEST) (envelope-from josemi@redesjm.local) Received: from localhost (localhost [[UNIX: localhost]]) by redesjm.local (8.13.3/8.13.3/Submit) id j5A0WZ15067872; Fri, 10 Jun 2005 02:32:35 +0200 (CEST) (envelope-from josemi@redesjm.local) From: Jose M Rodriguez To: Doug Barton Date: Fri, 10 Jun 2005 02:32:34 +0200 User-Agent: KMail/1.8 References: <42A8B4E6.9090401@FreeBSD.org> In-Reply-To: <42A8B4E6.9090401@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200506100232.34832.josemi@redesjm.local> X-AntiVirus: checked by AntiVir Milter (version: 1.1.0-3; AVE: 6.30.0.15; VDF: 6.30.0.207; host: antares.redesjm.local) Cc: ports@freebsd.org Subject: Re: Including PREFIX/etc/rc.d/* scripts in the system's rcorder for startup in 6.0-Release X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2005 00:32:39 -0000 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