Date: Fri, 28 Aug 1998 22:16:48 +0000 From: Mike Smith <mike@smith.net.au> 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 Message-ID: <199808282216.WAA00640@word.smith.net.au> In-Reply-To: Your message of "Fri, 28 Aug 1998 22:11:39 MST." <199808290511.WAA20198@burka.rdy.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199808282216.WAA00640>