From owner-freebsd-arch@FreeBSD.ORG Tue Feb 24 04:14: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 1B25916A4CE for ; Tue, 24 Feb 2004 04:14:58 -0800 (PST) Received: from postman.arcor.de (postman2.arcor-online.net [151.189.0.152]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5988143D2D for ; Tue, 24 Feb 2004 04:14:57 -0800 (PST) (envelope-from eikemeier@fillmore-labs.com) Received: from fillmore.dyndns.org (port-212-202-51-138.reverse.qsc.de [212.202.51.138]) (authenticated bits=0)i1OCEtf5000792 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 24 Feb 2004 13:14:56 +0100 (MET) Received: from [172.16.0.2] (helo=fillmore-labs.com) by fillmore.dyndns.org with esmtp (Exim 4.30; FreeBSD) id 1AvbSf-0003Ge-6O; Tue, 24 Feb 2004 13:14:53 +0100 Message-ID: <403B403C.7040701@fillmore-labs.com> Date: Tue, 24 Feb 2004 13:14:52 +0100 From: Oliver Eikemeier Organization: Fillmore Labs GmbH - http://www.fillmore-labs.com/ MIME-Version: 1.0 To: Mike Makonnen References: <20040223084146.GA4202@mobile.acs-et.com> <4039D9FF.40208@fillmore-labs.com> <20040224072401.GB1125@mobile.acs-et.com> <403B206B.7000101@fillmore-labs.com> <20040224103932.GA20467@mobile.acs-et.com> In-Reply-To: <20040224103932.GA20467@mobile.acs-et.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit User-Agent: KMail/1.5.9 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 12:14:58 -0000 Mike Makonnen wrote: > 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. I guess we agree here. I'll post a follow-up with uses ${PREFIX}/etc/{rc.conf,defaults/rc.conf,rc.conf.d} too. The problem here is that you'll have to support different prefixes, like /usr/X11R6. > 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. ... which this patch tries do. >>>>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. ${PREFIX}/etc/rc.conf.d files may be edited by the user, so you can't simply delete them. >>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. I get your point, but currently there is no way to convert *all* ports, we don't have the manpower to convert and test them all. So we need a transition path, where we may deprecate older scripts at some point. I guess we agree that ${PREFIX}/etc/rc.conf should be sourced by ports rc.d scripts, but this is not enough to integrate ports in rc.d without breaking the existing ports base. The patch, supplemented by ${PREFIX}/etc/{rc.conf,defaults/rc.conf,rc.conf.d} *is* a step forward in that direction. -Oliver