From owner-freebsd-ports@FreeBSD.ORG Sun Nov 30 20:50:09 2003 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 C8B3616A4CE; Sun, 30 Nov 2003 20:50:09 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id D689643FAF; Sun, 30 Nov 2003 20:50:05 -0800 (PST) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.9p2/8.12.9) with ESMTP id hB14lQMg043619; Sun, 30 Nov 2003 23:47:26 -0500 (EST) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)hB14lPKV043616; Sun, 30 Nov 2003 23:47:25 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Sun, 30 Nov 2003 23:47:24 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: "Maxim M. Kazachek" In-Reply-To: <20031201092813.X355@sbk-gw.sibnet.ru> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: ports@freebsd.org cc: Richard Coleman cc: Kris Kennaway cc: freebsd-current@freebsd.org cc: Oliver Eikemeier Subject: Re: Ports startup scripts in /etc/rc.d (Re: 5.2-BETA and related ports issues) 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: Mon, 01 Dec 2003 04:50:09 -0000 On Mon, 1 Dec 2003, Maxim M. Kazachek wrote: > On Sun, 30 Nov 2003, Richard Coleman wrote: For 5.2-RELEASE, I think we should ignore the whole issue and let the couple of ports that insert things in /etc/rc.d "just do it". We're not going to find any other solution in time to either close the discussion or test it properly. 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: (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. (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. (4) Continue to ignore the issue and let some ports install into /etc/rc.d and consider them unorthodox, incorrect, but something we can overlook. The devil isn't here, or at least, if it is, we'll overlook it. I'm actually leaning towards (2) as being the best solution, as it's easy and functional. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Senior Research Scientist, McAfee Research