Re: [PATCH 6/6] implement 'm' option for conffile merging during conflict resolution
On Mon, 28 Sep 2009, Sean Finney wrote:
> the conflict resolution prompt has been updated with a new option for
> automatic merging:
>
> Configuration file `<file>'
> ==> Modified (by you or by a script) since installation.
> ==> Package distributor has shipped an updated version.
> What would you like to do about it ? Your options are:
> Y or I : install the package maintainer's version
> N or O : keep your currently-installed version
> D : show the differences between the versions
> M : attempt to automatically merge the differences
> Z : background this process to examine the situation
> The default action is to keep your current version.
> *** foo.cfg (Y/I/N/O/D/M/Z) [default=N] ?
>
> this functions by performing a 3-way diff using the new conffile, the
> currently-installed conffile, and the pristine version of the conffile
> shipped in the currently installed package (in the conffile database).
Hum, instead of the "the pristine version of the conffile
shipped in the currently installed package", in theory it could also be the
ancestor of the currently installed conffile — that is the pristine version
of the conffile that last got installed (automatically or by a Y answer to
the prompt or by a successful merge).
Shouldn't that file be kept around as well and used in priority for the
merge? (In a conffiles-base directory for example)
P: pristine conffile of currently installed package
N: conffile of the new package to be installed
I: installed conffile
B: base conffile (last version successfully installed)
We could then try:
- diff(P → N) on top of I
- or diff(B → I) on top of N
That way a conffile upgrade skipped due to installations with
--force-confold can be recovered and the changes merged at the next
interactive upgrade.
We also want a --force-confmerge option to try out a merge
non-interactively before falling back to --force-confold/new.
> future implementations can extend this to allow for interactive inspection
> of failed merges, piping the diff to a pager, or perhaps even alternative
> diff3 implementations when available.
I would like to be able to review successful merges as well.
Cheers,
--
Raphaël Hertzog
Reply to: