From owner-freebsd-rc@FreeBSD.ORG Tue Feb 7 05:30:10 2006 Return-Path: X-Original-To: freebsd-rc@freebsd.org Delivered-To: freebsd-rc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CD62B16A420 for ; Tue, 7 Feb 2006 05:30:10 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by mx1.FreeBSD.org (Postfix) with SMTP id 549CD43D45 for ; Tue, 7 Feb 2006 05:30:10 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: (qmail 96307 invoked by uid 399); 7 Feb 2006 05:30:09 -0000 Received: from localhost (HELO ?192.168.1.102?) (dougb@dougbarton.us@127.0.0.1) by localhost with SMTP; 7 Feb 2006 05:30:09 -0000 Message-ID: <43E8305F.9020505@FreeBSD.org> Date: Mon, 06 Feb 2006 21:30:07 -0800 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 1.5 (X11/20060112) MIME-Version: 1.0 To: freebsd-rc@freebsd.org X-Enigmail-Version: 0.94.0.0 Content-Type: multipart/mixed; boundary="------------020304020308050203050202" Subject: rc.conf.d support for local_startup directories? X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2006 05:30:10 -0000 This is a multi-part message in MIME format. --------------020304020308050203050202 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Howdy, A post on -ports recently, and some other stuff I've been working on got me thinking. Is there any reason not to offer rc.conf.d support in the local_startup directories? I think that this would simplify a lot of issues, port authors could install the file with appropriate defaults, then deinstall it when they are done. No more messy stuff left over after a port is deinstalled. The only disadvantage I can see to this is that because of how the conf sourcing code is written, the variables in a file in an rc.conf.d directory will always override those in /etc/rc.conf[.local]. This could lead to two problems, one would be a potential POLA violation, the other is that there is a convenience factor now in just putting port_enable=yes in /etc/rc.conf.local, and having it still be there after you install the port. If rc.conf.d support became more widespread for ports, then users would have to either re-enable that port at every install, or (more likely) port authors would start enabling their port by default. One could make the argument that this is reasonable behavior, so I'm not sure this is a problem per se, just something to consider. There is at least one way around this problem that I can see off hand, but I thought I'd throw it open for discussion first and see what people think. I've attached the simplest implementation I could think of to start the discussion. Doug -- This .signature sanitized for your protection --------------020304020308050203050202 Content-Type: text/plain; name="local_startup-rc.conf.d-diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="local_startup-rc.conf.d-diff" Index: rc.subr =================================================================== RCS file: /usr/local/ncvs/src/etc/rc.subr,v retrieving revision 1.47 diff -u -r1.47 rc.subr --- rc.subr 10 Dec 2005 20:19:08 -0000 1.47 +++ rc.subr 7 Feb 2006 03:50:33 -0000 @@ -876,10 +876,12 @@ fi _rc_conf_loaded=true fi - if [ -f /etc/rc.conf.d/"$_command" ]; then - debug "Sourcing /etc/rc.conf.d/${_command}" - . /etc/rc.conf.d/"$_command" - fi + for dir in /etc $local_startup; do + if [ -r "${dir%/rc.d}/rc.conf.d/$_command" ]; then + debug "Sourcing ${dir%/rc.d}/rc.conf.d/${_command}" + . "${dir%/rc.d}/rc.conf.d/$_command" + fi + done # XXX - Deprecated variable name support # --------------020304020308050203050202--