question on mergemaster

[Garance A Drosihn]

At 12:05 PM -0500 1/19/04, Bill Moran wrote:
>
>But I just thought of a potential improvement, and I thought
>I'd suggest this to everyone and see what they think:
>
>If mergemaster checked each file for a magic value, such as:
># mergemaster autoreplace
>and automatically updated those files without prompting the
>user, then users could add such a line to the beginning of
>each file in /etc that they are comfortable updating without
>feedback.  It may seem like a lot of work, but it's only done
>_once_ (although mergemaster would need to be taught to
>preserve this magic when it updates the file)

I do not think this idea would work well in practice.

>The optimistic way to do this would be to have some sort of
>switch to mergemaster to tell it to go into autoupdate mode,
>and it will only ask for files that contain a "negative
>magic" like:        # mergemaster noautoreplace
>In which case the administrator should put this string at
>the beginning of every file that he tweaks in /etc

This is probably easier to implement, but there is still a
good chance that someone will make an important change to
some /etc file, and:
    1) not-know to add the line
       (documentation?  Who reads documentation?)
    2) know, but still forget to do it
    3) remember to do it, but misspell the magic line.

And at some future system update their change will be automatically
and quietly erased.  And depending on the change, they might not
realize that it is gone until weeks or months after having made
the mistake.

I think it would be a mistake if we streamline mergemaster to
the point that users can easily start losing updates.
   - - - -
My own view is that the biggest problem are the directories which
have lots of little files in them, where those files are often
related to each other.  The most obvious example is /etc/rc.d , but
there's also /etc/pam.d and maybe /etc/mail.

What I think would alleviate these issues is to implement a way
to tell mergemaster "treat all files in this directory as a
group".  The way I see this working is the user could specify
(in .mergemasterrc) which directories that they want to be treated
this way.  Let's say /etc/rc.d has been specified that way.  Then
if *any* file in /etc/rc.d has changed, mergemaster would first
give you a list of all filenames which have been changed in that
directory.  It would then tell the user something like:

   The following files have changed in /etc/rc.d :
      apm apmd bootparms  (etc...)
   The following files have been added to /etc/rc.d :
      addnoise gadfly

   Type 'ia' to install all new and changed files
   Type 'in' to install all new files, but prompt for changed files
   Default is to prompt for each file
   How should I handle the new and changed files in /etc/rc.d ?

That's just a rough idea.  I went with 'ia' and 'in' to be sure
the user has actually read this prompt, and isn't blindly entering
'i' because they misunderstood which prompt this was.  And I'm
sure the wording could be made better.  I think I would also like
some option there to *delete* any files which are in that directory
but are not in the "new installworld" of that directory.  For some
of these cases, it might also be reasonable to save a backup copy
of the directory in question.  That would also be useful if the
admin wants to compare all the "before" to all the "after" files at
some later time, even though they don't to do that while they are
in the middle of mergemaster-ing.

But to my way of thinking, if I could handle *all* the files in
/etc/rc.d, /etc/pam.d, /etc/mail and /etc/defaults by just typing
'ia' four times, that would greatly improve how mergemaster works
for me, and would introduce very very little risk.

But so far I haven't taken the time to try and implement these
ideas...

-- 
Garance Alistair Drosehn            =   gad at gilead.netel.rpi.edu
Senior Systems Programmer           or  gad at freebsd.org
Rensselaer Polytechnic Institute    or  drosih at rpi.edu