[ On Wednesday, January 9, 2002 at 17:55:24 (-0800), John Nemeth wrote: ]
> Subject: Re: Allowing ${name}_path to be set in "rc.conf", was Re: Keeping /etc/defaults and /etc/rc.d in-sync
>
> 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.

-- 
								Greg A. Woods

+1 416 218-0098;  <gwoods@acm.org>;  <g.a.woods@ieee.org>;  <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>