[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [PATCH 6/6] implement 'm' option for conffile merging during conflict resolution



Hi!

On Tue, 2009-09-29 at 12:17:02 +0200, Raphael Hertzog wrote:
> On Tue, 29 Sep 2009, sean finney wrote:
> > > 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)

I'll call P “D: dist”, to try to match more closely the current
nomenclature. And I think B should be instead:

  B: base conffile (last dist conffile after skipping an upgrade)

> > > We could then try:
> > > - diff(P → N) on top of I
> > > - or diff(B → I) on top of N
> > 
> > would you suggest that we do the latter first?  should they be seperate
> > options or something tried in succession as part of a single merge option?
> 
> I don't have a definitive answer. Both are useful depending on the
> scenario imagined.
> 
> I would suggest to do the latter first, and rewrite the "No" choices in
> two variants:
> - No, but keep changes for later merge
> - No, skip the changes introduced by this version
> 
> The second one would update the base file while the first one would not.

The base conffile only needs to be present when the installed conffile
has been modifed and it has been kept for more than one new conffile
upgrade.

So if it's present it would be used for the merge, something like:

  if (B exists)
    diff3 I B N
  else
    diff3 I D N

And cannot see why we'd want to fallback to use dist if the merge with
base does not work? dist is not going to be closer to inst if base is
present.

Once the changes relative to base have been merged into new, there's
no point in keeping it any longer, as the new base is now new, which
will become dist.

So I think this could be hooked in deferred_configure_conffile(), if
there's no base conffile, store one when “cfo_keep | cfof_backup”, as
this is the case were the new and inst conffiles have been changed,
and the user has been “prompted” and it's been decided to keep it.

And remove it when “cfo_install | cfof_backup”, as this is also the
case were the new and inst conffile have changed, and the user has
been “prompted”, and it's been decided to install the new version,
which implies either ignoring or taking the merged changes.

Something to consider is that currently on this later case, if the
user selected to ignore the local changes, a backup of the previous
modified conffile gets stotered as foo.dpkg-old, so we could decide to
store the base and the old inst conffiles in case the user wants to
recover those in the future. And not doing so in case of merge, either
automatic, or one done through the shell (which could be detected when
the inst candidate gets modified).

Does this sound right?

regards,
guillem


Reply to: