Re: pebkac, but is it a mergemaster bug?

Eygene Ryabinkin wrote:
>> Was mergemaster correct in its assesment that this file was a
>> candidate for automatic installation?
> 
> I'd say, "No it was mistaken". 

Overall I tend to agree with you, however I'll use this as yet another
reminder that my resistance to making mergemaster more "automatic" by
default has a solid basis.

> 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 auto-installed files are present
> in the list produced by the latter command and refuse to copy them
> over.

This situation with ntp.conf is the first time I remember that we've
ever added an example config file to the base that the user is likely
to have already in /etc (as opposed to /usr/local/etc which is where
user-originated stuff usually goes). So I'm not sure that this feature
as described is the most efficient way to solve the problem.

We just had a thread on this topic recently where I suggested that the
proper solution is to teach mtree to issue a list of files that have
_not_ changed and have mergemaster depend on that list instead of
getting the list of things that have changed and assuming that
anything not on that list is safe to replace.

Alternatively, if you really want to work on a patch that is for
mergemaster only you could get the list of files that have changed,
and parse the existing mtree db file against that list to generate a
list of files that have not changed.

> Doug, I am going to implement this stuff.  Maybe I am overseeing
> something and there are another ways to overcome this problem?  Will
> you commit such an extension to the mergemaster?

I currently lack the time to do the mtree stuff, but I will gladly
make the change to mergemaster if someone else can implement it.


hth,

Doug