From owner-freebsd-ports@FreeBSD.ORG Fri Jan 23 07:04:53 2004 Return-Path: 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 AAA5F16A4CE for ; Fri, 23 Jan 2004 07:04:53 -0800 (PST) Received: from argent.heraldsnet.org (argent.heraldsnet.org [64.83.41.80]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1723B43D2D for ; Fri, 23 Jan 2004 07:04:52 -0800 (PST) (envelope-from jtrigg@spamcop.net) Received: by argent.heraldsnet.org (Postfix, from userid 1001) id 96C1F39E; Fri, 23 Jan 2004 10:04:50 -0500 (EST) Date: Fri, 23 Jan 2004 10:04:50 -0500 From: Jim Trigg To: ports@freebsd.org Message-ID: <20040123150450.GH16715@spamcop.net> Mail-Followup-To: ports@freebsd.org References: <401136B5.7080906@fillmore-labs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <401136B5.7080906@fillmore-labs.com> User-Agent: Mutt/1.4.1i X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Subject: Re: Ports startup scripts in /etc/rc.d X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2004 15:04:53 -0000 On Fri, Jan 23, 2004 at 03:59:01PM +0100, Oliver Eikemeier wrote: > Robert Watson wrote: > > [...] > > >For 5.2-CURRENT, I think we should revisit this issue with one of the > >following conclusions winning out, and the rest being discarded as > >flame-bait: > > > >[...] > > > >(2) Reevaluate the order at routine points in the boot where new scripts > > might now be available (due to file system mounts or whatever). > > Essentially "insert the new cards into the deck, and shuffle". This > > requires rethinking of our current approach, which assumes a static > > order is created once at the start of the boot by rcorder(8). The > > devil will be in the big picture *and* the details of the > > implementation. > > > >(3) Add /local/etc/rc.d or /local/rc.d or /etc/local/rc.d or the like, a > > new directory that third party applications are allowed to modify > > during install, and that will be present for the creation of the > > static ordering by rcorder(8) early in the boot. The devil will be in > > the bikeshed, but the implementation is easy. > > > >[...] > > > >I'm actually leaning towards (2) as being the best solution, as it's easy > >and functional. > > An updated patch that does (2) is in PR 56736: > Having not spotted this thread earlier, I'll put my vote in for 3 -- it's trivial to implement, and doesn't generate places for unexpected issues to spring up. I'd choose either /etc/local/rc.d/ or /etc/rc.d/local/. Jim Trigg -- Jim Trigg, Lord High Everything Else O- /"\ \ / ASCII RIBBON CAMPAIGN Hostmaster, Huie Kin family website X HELP CURE HTML MAIL Verger, All Saints Church - Sharon Chapel / \