About mergemaster (Re: upgrading)

[Mike Porter]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tuesday 23 September 2003 11:21 am, Jason Andresen wrote:
> Jim C. Nasby wrote:
> > On Tue, Sep 23, 2003 at 09:25:10AM -0700, Doug White wrote:
> >>In 99% of cases, there is no CVS repo to compare against.
> >
> > Huh? What about the main FBSD CVS repository?
>
> Mergemaster is typically run in single user mode.  Unless you're running
> mergemaster on a CVS mirror, you're not going to be able to get at it.

That's why a simple hash of the file, which could be generated at install is 
probably the easiest way to go:

generate hash of the existing file, compare to the stored hash, if they are 
the same, the file hasn't changed, install the new file (or prompt once for 
confirmation, rather than requiring the user to page through all the diffs 
for a file they don't really care about, but preserves the option of viewing 
the 'normal' mergemaster output....for example, /etc/defaults/rc.conf, which 
should never be changed, but you may find that a setting that used to be on, 
is now off (or vice versa) requiring a new line in /etc/rc.conf.).

This would handle the majority of cases.  

However, as I have thought about this problem, a different solution presents 
itself: a more sophisticated compare mechanism.

If, instead of simply comparing the 'installed' version of a file to the 'new' 
version of a file, what if mergemaster could distinguish between changes to 
the base file, and changes to 'defaults'.  For example, in my /etc/aliases, I 
have the line "root:  mupi"  As it stands, mergemaster always prompts me for 
this file, because, of course, the original file reads "# root:    
me at my.domain".  However, I can't just choose (k)eep my installed version, 
becuase there may be other changes to the aliases file, espcially if a new 
user was created for some function, that user would typically point back to 
root via the alias file, so there will be ahcnage there.  I also don't want 
to just (i)nstall the new version, becuase then I would have to go back and 
add that line back in.  Granted, it isn't bad, when I am only looking at one 
line, but what about, say /etc/passwd, where I could have to go in and check 
each user?

A better method would be to compare the original /etc/aliases (before my edit) 
to the new /etc/aliases, and see of any changes have been made, and then 
merge only changes from the original file back in to the installed file.  
this would preserve my edits to /etc/aliases, while still allowing for any 
new additions or removal of obsolete aliases.  The same approach would work 
splendily with /etc/passwd, /etc/groups, /etc/printcap and /etc/hosts, which 
are files we pretty much *know* are going to have been changed.  It should 
work for most everything else, as well, and would preserve any local edits.  
The one scenario it would still break is if a change conflicts with an 
existing line (for example, we add a new system user with the same uid as an 
existing user, or change the alias of root in /etc/aliases from 
"me at my.domain" to "me at my.full.domain".  We'd want a detection mechnism for 
that sort of thing ("does the line I am about to append to this file conflict 
with any existing lines?  If so, ask for confirmation before making the 
change"  Done right, this would allow changes to comments as well, whether 
just to correct a typo or to document new functionality.  Of course, this 
comparison logic would be a devil to implement...it would be easy to simply 
append the new lines to the bottom of the file, but you can't just blindly 
delete lines from the installed file, without first checking if it is the 
line we want to delete.  I don't know if diff/patch are smart enough to 
handle this.  I think some experimentation is in order....

mike
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (FreeBSD)

iD8DBQE/cLzjY30jZzkECLcRAt/XAJ99n1BbjMkSkqp4qhJA5gnjKdnQBgCgtN94
vhQ8Bj1bvFRfPrYVmGfxo6U=
=wLiy
-----END PGP SIGNATURE-----