Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 6 Jul 2009 13:43:04 +0400
From:      Eygene Ryabinkin <rea-fbsd@codelabs.ru>
To:        Ian Freislich <ianf@clue.co.za>, dougb@freebsd.org
Cc:        current@freebsd.org
Subject:   Re: pebkac, but is it a mergemaster bug?
Message-ID:  <JihCfvLYurSbwCvYPMTikKEUsuo@OeoW5JVkL3r5Dz%2BLWqlFPl5E0fc>
In-Reply-To: <E1MNOcw-0001uh-K3@clue.co.za>
References:  <E1MNOcw-0001uh-K3@clue.co.za>

next in thread | previous in thread | raw e-mail | index | archive | help
Ian, Doug, *, good day.

Sun, Jul 05, 2009 at 12:07:18PM +0200, Ian Freislich wrote:
> Due to not paying attention my ntp.conf on several of my time servers
> was updated (and broken) by mergemaster.  I had the automatic update
> options set for files that I had not modified.  My ntp.conf had no
> VCS id and the files differed, obviously.

What happened is the following: when mergemaster does automated
upgrades, it consults the existing mtree database in
/var/db/mergemaster.mtree that carries information about the state
of the files created when the temproot was populated.  When you start
mergemaster, it will use the saved database from the previous run, so
when you was hit the ntp.conf issue, that file was not in the mtree
database yet.

When mergemaster determines the list of changed files for auto-upgrade
($CHANGED), it just runs mtree against the current contents of the
DESTDIR and looks for the 'changed' lines.  Mtree is invoked with '-e',
so it won't pay attention to the files that are present in the file
hierarchy (your own /etc/ntp.conf), but not in the specification
(remember, mtree database is from the previous run, so ntp.conf isn't
there yet).

And when a decision on the file's auto-upgrade is done, the following
sequence is invoked:
 - mm checks that both source and destination files are present (your
   case);
 - mm checks that the destination file name isn't in the ${CHANGED}
   list (it isn't, as explained in the previous paragraph).

So, it's how your ntp.conf ended up overwritten (if I am catching
mm's logics well).


> Was mergemaster correct in its assesment that this file was a
> candidate for automatic installation?

I'd say, "No it was mistaken".  Basically, there should be a way to
determine new files that were added to the tree since the last
mergemaster run.  And there is a way:
-----
mtree -f ${MTREENEW} -f ${MTREEFILE} | \
  awk '/^[^[:space:]]/ && $2 == "file" { print $1; }'
-----
So, we should additionally check if the auto-installed files are present
in the list produced by the latter command and refuse to copy them
over.

Doug, I am going to implement this stuff.  May be I am overseeing
something and there are another ways to overcome this problem?  Will
you commit such an extension to the mergemaster?
-- 
Eygene
 _                ___       _.--.   #
 \`.|\..----...-'`   `-._.-'_.-'`   #  Remember that it is hard
 /  ' `         ,       __.--'      #  to read the on-line manual
 )/' _/     \   `-_,   /            #  while single-stepping the kernel.
 `-'" `"\_  ,_.-;_.-\_ ',  fsc/as   #
     _.-'_./   {_.'   ; /           #    -- FreeBSD Developers handbook
    {_.-``-'         {_/            #



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?JihCfvLYurSbwCvYPMTikKEUsuo>