From owner-cvs-all Fri Aug 28 22:20:11 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA12680 for cvs-all-outgoing; Fri, 28 Aug 1998 22:20:11 -0700 (PDT) (envelope-from owner-cvs-all) Received: from word.smith.net.au (castles244.castles.com [208.214.165.244]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA12660 for ; Fri, 28 Aug 1998 22:20:07 -0700 (PDT) (envelope-from mike@word.smith.net.au) Received: from word.smith.net.au (localhost [127.0.0.1]) by word.smith.net.au (8.9.1/8.8.8) with ESMTP id WAA00640; Fri, 28 Aug 1998 22:16:49 GMT (envelope-from mike@word.smith.net.au) Message-Id: <199808282216.WAA00640@word.smith.net.au> X-Mailer: exmh version 2.0.2 2/24/98 To: dima@best.net cc: mike@smith.net.au (Mike Smith), dillon@backplane.com, jkh@time.cdrom.com, committers@FreeBSD.ORG Subject: Re: make.conf In-reply-to: Your message of "Fri, 28 Aug 1998 22:11:39 MST." <199808290511.WAA20198@burka.rdy.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 28 Aug 1998 22:16:48 +0000 From: Mike Smith Sender: owner-cvs-all@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Mike Smith writes: > > That would imply a minimum of conflict between an automatically > > upgraded /etc/rc.conf and your scheme; because you leave /etc/rc.conf > > untouched, the upgrade would simply migrate it to the newer version, > > but your overrides would be left untouched. > > > > The one difficult case would be where a new addition to /etc/rc.conf > > was made which enabled a service which you wanted disabled. > > I don't see a problem here, since rc.conf.local is included at the very end > of /etc/rc.conf. Or am I missing something? In the following scenario, it requires an audit as Matt mentioned: - You perform an operating system upgrade, which updates /etc/rc.conf - The upgrade adds a new service to the standard system startup - The update of /etc/rc.conf enables this new service - You do not want this new service enabled Because the existing rc.conf.local doesn't know about the new service, it won't contain an override to turn it off. This case is likely to be so rare that while it's worth bearing in mind, I can't see it as something to preclude using an automated update tool. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com