[ On Tuesday, February 4, 2003 at 10:32:58 (+0000), David Laight wrote: ]
> Subject: Re: bin/20200: Let etcupdate skip files with strictly local modifications (patch)
>
> It seemed to me that you needed to know the file that the user
> had started with.  Then you can tell whether there are any local
> modifications, if not it is (probably) safe to install the new
> version of the file.

Yes, absolutely -- I've been harping over this for years.  Though the
trick with RCS ID strings works well enough for identifying that changes
have been made to the "master" version of at least those files which
contain RCS ID strings, it does nothing at all to help anyone do a
proper merge of those changes if they don't have access to the full
change delta information.

> If the master file has changed, and the user has added local config
> stuff, then the user (probably) needs to fix his file to incorporate
> the standard changes.  Something like the CVS diff merging code
> might actually work - especially if there are no conficts.

CVS doesn't do anything special -- it just calls diff3.

> This does require that the issue files for /etc be kept somewhere
> on the target system.  /etc/.issue/* could be used.

Yes, either there, or perhaps under /usr/share/examples maybe?

The trick is of course that the delta of the new master revision must be
obtained before the old master is over-written!  ;-)

I once had a nefarious plan to replace the use of RCS in /var/backups
with CVS and use the existing vendor branch support in CVS.  Postinstall
would "cvs import" the original master files, and then check out a
working directory with the local changes merged in and offer to copy the
resulting files back to their runtime locations.  Then the next run of
/etc/security would check in the new local version, complete with the
merges in the case of an upgrade and any new local changes.

However I think using the CVS vendor branch trick in /var/backups is a
bit of an over-kill for binary installs -- simply doing a diff3 of the
new master revision against the old one and the installed local file
would suffice to allow a safe merge -- and it's probably safer to keep
the original master files anywhere but under /var.  There's also really
no need for every system to maintain all the deltas of all the upgrades,
especially not when that same information is publicly available in much
more detail from the original master CVS repository if/when it's
actually needed by anyone -- most sites only need the newest delta when
they're actually doing an upgrade and if the original master files are
kept then that's immediately available with a simple diff.

Either way it would be nice to be able to run the /var/backups part of
/etc/security separate from /etc/security -- I think I'll break it out
in my version regardless of how the upgrade procedure ends up working.

-- 
								Greg A. Woods

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