On Apr 26,  1:52pm, Greg A. Woods wrote:
} [ On Wednesday, January 9, 2002 at 17:55:24 (-0800), John Nemeth wrote: ]
} > On Apr 21,  9:43am, Greg A. Woods wrote:
} > } [ On Friday, January 4, 2002 at 17:09:52 (-0500), Andrew Brown wrote: ]
} > } >
} > } > the whole point of having a /etc/defaults directory and then a layer
} > } > above that people can wreck is that systemic upgrades *won't* require
} > } > a three-way merge.  i like it the way it is.  i guess we'll have to
} > } > disagree.  :-/
} > } 
} > } Since we were talking about the /etc/rc.d/* scripts, and how to go about
} > } better supporting upgrades in face of end-user changes to these scripts,
} > } you simply cannot avoid a three way merge without adding so much
} > } complexity that there's not likely any chance anyone would ever modify
} > } the scripts in the first place.
} > 
} >      I just did an upgrade on a Solaris system.  What it did in some
} > cases was to rename something to X.old and put in a new X and in other
} > cases it kept my X and just created an X.new.  It logged all this and
} > left it to me to sort out.  This obviously isn't a completely automated
} > system, but it did preserve changes during the upgrade.  I assume it
} > had some kind of database (md5 hashes?) so that it could determine what
} > was changed.
} 
} Hmmm... and you're left to figure out what changes you've made, or
} conversely what changes they made, without either of you having kept an
} "ancestor" version of the file.  I.e. you now need to do a three-way
} merge but you've only got two revisions to work with.  Oops.  Surely we
} can do better.

     Granted.  I was trying to say that it was the best.  Just a
stepping stone in the right direction.  I.e. it didn't arbitrarily
overwrite changes and throw them out.  It kept as much as it could,
which is somewhat better than sysinst which simply does "mv /etc
/etc.old".  Of course, it also added lines to inetd.conf to enable
services that I had deliberately disabled.

}-- End of excerpt from Greg A. Woods