From owner-freebsd-arch@FreeBSD.ORG Tue Feb 24 02:39:58 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AA43516A4CF for ; Tue, 24 Feb 2004 02:39:58 -0800 (PST) Received: from telecom.net.et (sparrow.telecom.net.et [213.55.64.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0694643D1F for ; Tue, 24 Feb 2004 02:39:55 -0800 (PST) (envelope-from mtm@identd.net) Received: from [213.55.65.39] (HELO pool-151-200-10-97.res.east.verizon.net) by telecom.net.et (CommuniGate Pro SMTP 3.4.8) with ESMTP-TLS id 37438375; Tue, 24 Feb 2004 13:34:03 +0300 Received: from mobile.acs-et.com (localhost [127.0.0.1]) ESMTP id i1OAdaQk020530; Tue, 24 Feb 2004 13:39:39 +0300 (EAT) (envelope-from mtm@mobile.acs-et.com) Received: (from mtm@localhost) by mobile.acs-et.com (8.12.10/8.12.10/Submit) id i1OAdaPA020529; Tue, 24 Feb 2004 13:39:36 +0300 (EAT) (envelope-from mtm) Date: Tue, 24 Feb 2004 13:39:32 +0300 From: Mike Makonnen To: Oliver Eikemeier Message-ID: <20040224103932.GA20467@mobile.acs-et.com> References: <20040223084146.GA4202@mobile.acs-et.com> <4039D9FF.40208@fillmore-labs.com> <20040224072401.GB1125@mobile.acs-et.com> <403B206B.7000101@fillmore-labs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <403B206B.7000101@fillmore-labs.com> User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD/5.2-CURRENT (i386) cc: freebsd-arch@FreeBSD.org Subject: Re: rc.d and ports X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2004 10:39:58 -0000 On Tue, Feb 24, 2004 at 10:59:07AM +0100, Oliver Eikemeier wrote: > > I guess I don't fully understand what modifications you suggest for the > ports. What is needed to fit into rc.d? The modification I ask for in my initial email :-) If ports want to be a part of rc.d then they must use appropriate rc.d mechanisms. My rc.d modification to support /usr/local/etc/{rc.conf,defaults/rc.conf,rc.conf.d} are necessary so that ports configuration knobs don't pollute the enviroment for base system scripts. But other than that, it should be up to the ports to fit into the rc.d scheme. The problem with your patch is that it is a bunch of hacks to rc.d to semi-incorporate ports into the rc.d mechanism. My point is: don't hack rc.d to semi-incorporate ports. Instead, we should fully incorporate ports into rc.d. > >> > >>I guess we don't need this (and shouldn't do it, since > >>${PREFIX}/etc/defaults/rc.conf > >>might be read-only). Defaulting xxx_enable to "NO" seems to be > >>sufficient, with > >> > >>[ -z "$xxx_enable" ] && xxx_enable="NO" > >>or > >>xxx_enable=${xxx_enable:-"NO"} > >>before calling load_rc_config $name > > > >Again, why special-case ports scripts ? > > Because the defaults belong to the port, not to the base system. I want them > to go away with the port. Nobody (and especially not ports) should edit > whatever/defaults/rc.conf, and how would I otherwise cope with the situation > that default flags may change? Then the ports can use /usr/local/etc/rc.conf.d. When the port is deleted it can just delete the appropriate conf file in that directory without the need to edit any files. > > I guess I incorporate ${PREFIX}/etc/defaults/rc.conf and another change in > PR 56736, the main point there was that I wanted them to participate in > rcorder, > which I believe is a good thing, especially when you consider the > possibility > to move sendmail or other parts of the base system to ports. > > So I understand that sourcing ${PREFIX}/etc/defaults/rc.conf is the main > reservation that you have against this patch? No. As I have tried to state already I don't like it because it is an unnecesary hack. As for participating in rcorder(8), first the ports have to support all the rc.d mechanisms. Your patch simply hacks rc.d to allow those ports that choose to use some of the rc.subr functionality to participate in rcorder(8)ing. What should happen is that our ports infrastructure should fully support rc.d and all ports scripts should be modified to work with rc.d. Otherwise, we will have lots of confused users wondering why some ports are ordered with the base system scripts and others are not. Cheers. -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc mtm@identd.net | Fingerprint: AC7B 5672 2D11 F4D0 EBF8 5279 5359 2B82 7CD4 1F55 mtm@FreeBSD.Org| FreeBSD - Unleash the Daemon !