From owner-freebsd-current@FreeBSD.ORG Sun May 30 05:03:15 2004 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 0B29516A4CE; Sun, 30 May 2004 05:03:15 -0700 (PDT) Received: from cs1.cs.huji.ac.il (cs1.cs.huji.ac.il [132.65.16.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id BB9CF43D31; Sun, 30 May 2004 05:03:14 -0700 (PDT) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32] ident=danny) by cs1.cs.huji.ac.il with esmtp id 1BUP1u-000Nsh-Kr; Sun, 30 May 2004 15:03:06 +0300 X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4 To: Andre Guibert de Bruet In-Reply-To: Message from Andre Guibert de Bruet <20040529111209.B16672@alpha.siliconlandmark.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Sun, 30 May 2004 15:03:06 +0300 From: Danny Braniss Message-Id: <20040530120314.BB9CF43D31@mx1.FreeBSD.org> cc: ports@freebsd.org cc: current@freebsd.org Subject: Re: /usr/local/etc/rc.conf 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: Sun, 30 May 2004 12:03:15 -0000 > = > On Sat, 29 May 2004, Patrick Tracanelli wrote: > = > > I remember it has been discussed before, but the terms were a little = bit > > different, so tell me, isn't it appropriate rc.subr to suck the > > configuration parameters from /usr/local/etc/rc.conf instead of > > /etc/rc.conf when running startupscripts for third party applications= > > (/usr/local/etc/rc.d/)? > > > > To keep the organization principles, I dislike putting those > > instructions into /etc/rc.conf when it should be read by 3rd party ap= ps, > > since I consider /etc/ to be used by the base system. Altho' old styl= e > > .sh scripts are still usefull under ${local_startup} dirs, ports > > maintainers tend to write new style rc scripts that uses rc.subr to r= ead > > the user defined options (usually via /etc/rc.conf). > > > > Easy solution would be > > > > rc_conf_files=3D"/etc/rc.conf /etc/rc.conf.local /usr/local/etc/rc.co= nf" > > > > into /etc/rc.conf, but it seems to be ignored by rc.subr when it's no= t > > at /etc/defaults/rc.conf; > > > > Some 3rd party startupscripts read rc.subr from /usr/local/etc/, so i= f > > it suck only ${PREFIX}/etc/rc.conf options, would force users to > > configure it in the right place, but it would break POLA and since so= me > > scripts read /etc/rc.subr instead if ${PREFIX}/etc/rc.subr, would als= o > > break some ports (very very bad idea). > > > > So, to allow ports startupscript to be configured from > > /usr/local/etc/rc.conf but also prevent people who are today used to = mix > > everything in /etc/rc.conf from having their app. not starting, defin= ing > > > > rc_conf_files=3D"/etc/rc.conf /etc/rc.conf.local /usr/local/etc/rc.co= nf" > > > > into /etc/defaults/rc.conf would just do it, nothing would break and > > port's pkg-message could start trying to educate users to populate > > /usr/local/etc/rc.conf for ports startup options and leaving > > /etc/rc.conf only for the base system... > = > Having multiple locations for system startup parameters (A l=E0 Windows= ) is > a maintenance headache even when there's a logical method to the > madness. I'm saying this as the admin of 6 racks packed with 1U and 2U > machines. Be gentle... ;) > = and some of us (i hope more than one), have /usr/local shared among many.= danny