From owner-freebsd-stable Wed Feb 14 8:59:45 2001 Delivered-To: freebsd-stable@freebsd.org Received: from yez.hyperreal.org (penelope.ny.collab.net [64.61.9.189]) by hub.freebsd.org (Postfix) with SMTP id 29DBB37B65D for ; Wed, 14 Feb 2001 08:59:39 -0800 (PST) Received: (qmail 1506 invoked by uid 1000); 14 Feb 2001 17:00:18 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 14 Feb 2001 17:00:18 -0000 Date: Wed, 14 Feb 2001 09:00:18 -0800 (PST) From: Brian Behlendorf X-X-Sender: To: Doug Barton Cc: Greg Troxel , , Kris Kennaway Subject: Re: Upgrading config files (Was: Re: sshd in 4.2-STABLE) In-Reply-To: <3A8A1CF3.264A5C70@gorean.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 13 Feb 2001, Doug Barton wrote: > So, the question now is, does upgrading by default without forcing the > user to see the changes unload the gun, or just point it at a different > foot? The way I see it, when I do a make world, there are *lots* of things being upgraded without my awareness. The fact that something is being changed in /sbin/init is not all that different than something being changed in /etc/rc or /dev/MAKEDEV. I don't track changes in the first case (unless I follow cvs commits) and I probably won't care in the latter. I'm hard pressed to think of a file that, if I didn't edit at some point, I would care about being updated. > My feeling is that all we're doing is replacing one set of > problems with another, and losing the opportunity to educate the users > in the process. I have long been an advocate of both making "The Right > Thing" easier to understand and to accomplish, but at some level you > just can't make unix system administration any easier. There are tradeoffs, certainly. I wouldn't argue for making the replace-unless-changed algorithm the default, at least not at this point until people had a chance to work with it and found any hidden gotchas that such an approach has. Brian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message