From owner-freebsd-hackers@FreeBSD.ORG Fri Jun 19 05:24:47 2009 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9A1231065680 for ; Fri, 19 Jun 2009 05:24:47 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id 280D68FC1D for ; Fri, 19 Jun 2009 05:24:47 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: (qmail 23236 invoked by uid 399); 19 Jun 2009 04:58:03 -0000 Received: from localhost (HELO foreign.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 19 Jun 2009 04:58:03 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4A3B1AD9.90507@FreeBSD.org> Date: Thu, 18 Jun 2009 21:58:01 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 2.0.0.21 (X11/20090423) MIME-Version: 1.0 To: =?UTF-8?B?RGFnLUVybGluZyBTbcO4cmdyYXY=?= References: <200906071326.n57DQvSG095104@svn.freebsd.org> <86iqiudm63.fsf@ds4.des.no> <4A3A88BD.5030703@FreeBSD.org> <86ab455gop.fsf@ds4.des.no> In-Reply-To: <86ab455gop.fsf@ds4.des.no> X-Enigmail-Version: 0.95.7 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: hackers@freebsd.org, Edwin Groothuis Subject: Re: svn commit: r193635 - head/etc X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2009 05:24:48 -0000 Dag-Erling Smørgrav wrote: > Doug Barton writes: >> Dag-Erling Smørgrav writes: >>> Great, now mergemaster blew away my ntp.conf and installed this one >>> instead. Apparently, it thinks AUTO_UPGRADE means it's fine to >>> overwrite an existing file with a new one... >> Yes, that's exactly what the option means. The problem comes in >> because it's a new file, which means that there is no record of it in >> the mtree file, so it does not show up as "changed." > > Hmm, I'm not sure I follow, since I'm not familiar with the innards of > mergemaster, The -U option works by comparing the installed files to the mtree file created from the unmodified source files. If the file is listed as having been changed, the -U option ignores it. If not, it auto-installs it. > but can you tell it's new? If you can, you can check if > there's already a file of the same name before installing the new one? The whole point of the option is to automatically overwrite the existing file if it isn't listed as being changed. >> FWIW, this is one of the reasons that I resisted the idea of using >> mtree for this function, and continue to resist the idea of the -U >> option being the default. > > I didn't realize it was the default - but I really, really like it. It > makes mergemaster a *lot* easier to use. It's not the default. Corner cases like this one are the reason I resist making it the default. >> There is no way that I can see to have mtree list the files that have >> _not_ changed, which would be the safest way to implement this >> option. > > Doesn't sound unsurmountable. > >> Meanwhile I'm sure you were able to restore from backups > > Of course (not that there was much to restore - just "server ntp.des.no > iburst maxpoll 6"), and now that I know about it, I can list it in > IGNORE_FILES along with motd and printcap. Now that you've had a successful run with the new sources the signature for the stock file will be in mergemaster's mtree file so you won't have to worry. You might also consider adding the svn Id for the source file which will allow mergemaster to ignore it altogether at least until it changes. hope this helps, Doug -- This .signature sanitized for your protection