From owner-freebsd-current@FreeBSD.ORG Mon Dec 1 14:28:20 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 33E7C16A4CE; Mon, 1 Dec 2003 14:28:20 -0800 (PST) Received: from mail.dt.e-technik.uni-dortmund.de (krusty.dt.E-Technik.Uni-Dortmund.DE [129.217.163.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 925F243FBF; Mon, 1 Dec 2003 14:27:35 -0800 (PST) (envelope-from ma@dt.e-technik.uni-dortmund.de) Received: from m2a2.dyndns.org (krusty.dt.e-technik.uni-dortmund.de [129.217.163.1])AEFBF16A39; Mon, 1 Dec 2003 23:27:34 +0100 (CET) Received: by merlin.emma.line.org (Postfix, from userid 500) id B49DBA0801; Mon, 1 Dec 2003 23:27:31 +0100 (CET) To: Robert Watson In-Reply-To: (Robert Watson's message of "Sun, 30 Nov 2003 23:47:24 -0500 (EST)") References: From: Matthias Andree Date: Mon, 01 Dec 2003 23:27:31 +0100 Message-ID: User-Agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii cc: ports@freebsd.org cc: Richard Coleman cc: freebsd-current@freebsd.org cc: Oliver Eikemeier cc: Kris Kennaway cc: "Maxim M. Kazachek" Subject: Re: Ports startup scripts in /etc/rc.d (Re: 5.2-BETA and related ports issues) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Dec 2003 22:28:20 -0000 Robert Watson writes: > (1) Combine / and /usr into a single file system by default, and add > /usr/local/etc/rc.d to the search order, with appropriate hacks to > handle old-style scripts. The devil will be in the bikeshed, but the > implementation is easy, except for the bit where we explain that > NFS-mounted /usr/local won't work too well. I'd discourage that. It's fairly intrusive and breaks existing setups. I'm NOT going to repartition and reinstall! > (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. I don't think there shall be devils in the implementation details. I admit not having looked at rcorder yet, but dependencies can be passed on from one rcorder run to the next, through the usual process environment. > (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. /etc/local/rc.d might work, it's quite similar to the /etc/opt approach "configuration stuff for /opt applications" on Linux. > I'm actually leaning towards (2) as being the best solution, as it's easy > and functional. Seconded from the user's view. -- Matthias Andree Encrypt your mail: my GnuPG key ID is 0x052E7D95