From owner-freebsd-current@FreeBSD.ORG Thu May 27 01:52:36 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 5C8F716A4DB; Thu, 27 May 2004 01:52:36 -0700 (PDT) Received: from mailhub02.unibe.ch (mailhub02.unibe.ch [130.92.9.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1A4C043D2D; Thu, 27 May 2004 01:52:36 -0700 (PDT) (envelope-from roth@speedy.unibe.ch) Received: from localhost (scanhub01.unibe.ch [130.92.254.65]) by mailhub02.unibe.ch (Postfix) with ESMTP id 37D7276547; Thu, 27 May 2004 10:51:58 +0200 (MEST) Received: from mailhub02.unibe.ch ([130.92.9.53]) by localhost (scanhub01 [130.92.254.65]) (amavisd-new, port 10024) with LMTP id 28658-02-25; Thu, 27 May 2004 10:51:57 +0200 (CEST) Received: from asterix.unibe.ch (asterix.unibe.ch [130.92.64.4]) by mailhub02.unibe.ch (Postfix) with ESMTP id EAF3876511; Thu, 27 May 2004 10:51:13 +0200 (MEST) Received: from speedy.unibe.ch (speedy [130.92.64.35]) by asterix.unibe.ch (8.11.7p1+Sun/8.11.7) with ESMTP id i4R8n4u10965; Thu, 27 May 2004 10:49:04 +0200 (MET DST) Received: (from roth@localhost) by speedy.unibe.ch (8.12.10+Sun/8.12.9/Submit) id i4R8n3kq017263; Thu, 27 May 2004 10:49:03 +0200 (MEST) Date: Thu, 27 May 2004 10:49:03 +0200 From: Tobias Roth To: Oliver Eikemeier Message-ID: <20040527084903.GA17193@speedy.unibe.ch> References: <40B2B7D4.5040106@users.sourceforge.net> <20040525210812.9728A5D08@ptavv.es.net> <20040526181624.GB55179@empiric.dek.spc.org> <40B5899E.7030506@fillmore-labs.com> <20040527073700.GA16531@speedy.unibe.ch> <40B5A069.8080909@fillmore-labs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40B5A069.8080909@fillmore-labs.com> User-Agent: Mutt/1.4i X-message-flag: Warning! Using Outlook is insecure and promotes virus distribution. Please use a different email client. X-Virus-checked: by University of Berne cc: freebsd-current@freebsd.org cc: freebsd-rc@freebsd.org Subject: Re: ports and /etc/rc.d/ [was: Where to put my own startup script] 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: Thu, 27 May 2004 08:52:36 -0000 On Thu, May 27, 2004 at 10:01:45AM +0200, Oliver Eikemeier wrote: > > > >1) ports startup scripts use rc.subr and get a common structure (good) > >2) with a common structure, rcorder can be used for ports as well (good) > >3) /etc/rc.d/ and /usr/etc/rc.d/ get mixed up (bad) > > You meant /usr/local/etc/rc.d/ here? yes > >4) ports can be started early in the boot process (good, ie for things like > > racoon) > >5) /etc/rc.conf contains directions about ports and is not just a subset of > > /etc/defaults/rc.conf anymore (bad, same thing as 3) > > > >we tend towards 1) already. once a decision about the other points has been > >taken, what's left is that all ports are (slowly) converted to this. > >an update to the porters handbook and after a while, a warning when an > >old-style startup script will be executed is the way to go. > > > >2) will be very nice. PR 56736 from eik seems to address this very > >elegantly. ports that need to be started early can be started directly > >after > >the dummy PORTS dependency, all others that do not explicitly request a > >specific startup order should be started at the end of rc.d/. this of > >course also solves 4). > > You should not really use PORTS, but whatever you need to run. i don't understand what you mean by that. i was just trying to briefly describe what your patch from PR 56736 does. maybe i got it wrong? > >now, shouldn't racoon be started before mountcritremote? #$%#!#, i think > >i just shot myself in the foot. comments please :-) i am sure that can > >be fixed elegantly as well. > > The problem here is that /usr might not be a local filesystem, so touching > anything there before mountcritremote is not a really good idea. that is exactly what i wanted to say. since racoon might be needed to mount remote filesystems, and at the same time possibly being located on one, we have a problem. more comments about adapting PR 56736 and reverting 3) ?