Re: [PATCH 6/6] implement 'm' option for conffile merging during conflict resolution
On Tue, 29 Sep 2009, sean finney wrote:
> if i understand you correctly:
>
> - pristine packaged conffile stored during unpack
> - successfully installed conffiles (Y or post-merge) stored during or
> after configuration
> - during conflict resolution, multiple merge paths are tried (or offered?)
>
> is that correct?
Yes. Not sure what the proper UI is. Either the choice of the merge path is
automatic based on what works and what not, or we can let the user select
it by offering two types of merges.
> > Shouldn't that file be kept around as well and used in priority for the
> > merge? (In a conffiles-base directory for example)
>
> i suppose it could be useful for a "show me what's changed since the
> last conffile conflict/resolution", and cases where the conffile was
> further modified after a successful resolution.
>
> it does complicate things a bit though--not so much in implementation
> which is fairly straightforward, but more with the installation process
> (see below wrt the merge reviewing)
Indeed.
>
> > 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
>
> 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.
> > That way a conffile upgrade skipped due to installations with
> > --force-confold can be recovered and the changes merged at the next
> > interactive upgrade.
>
> i could be missing something since i'm only passingly familiar with
> a few codepaths in dpkg, but i think that we still get the conffiles
> into the conffile db even when --force-confold is passed (since the
> hook into this is pretty early, during unpack) i'll see if i can
> verify this tonight.
You get the new conffile in the DB yes, but if the installed conffile has
not been updated (due to --force-conffold), then you have no way to
reintroduce the changes that were not applied if you haven't kept around
the base file.
Imagine a conffile that is modified two times (CF1 → CF2 → CF3). If you
install v2 with --force-conffold you get CF1 installed. When you install
v3 interactively you have no chance to catch up and include the changes
from CF1 → CF3, you will only be offered to merge the changes CF2 → CF3.
If we keep a base file around, we know that CF1 is the last version
installed/merge and we can include both changes too.
So in fact we have 3 ways to do the merge:
- diff(P → N) on top of I
- diff(B → N) on top of I
- diff(B → I) on top of N
Urgh.
> > We also want a --force-confmerge option to try out a merge
> > non-interactively before falling back to --force-confold/new.
>
> yeah i think that'd be a nice idea.
(Reading myself saying "we want" I realize I'm a bit too strong in my
wording, at least it meant that if I were working on this I would also
implement this for consistency with the existing options)
> yeah. the only problem is that it adds an extra step to the installation
> process (i.e. an extra prompt) so i figured that this (as well as stuff
> like the new suggestions above) should be hammered out in discussion for
> exactly how it should work, prompt strings, etc, and also seperate from
> the initial implementation.
Sure.
> ssh://git.debian.org/git/users/seanius/dpkg.git
> http://git.debian.org/git/users/seanius/dpkg.git
I prefer this one:
git://git.debian.org/~seanius/dpkg.git
Shorter and using the optimized git server.
Cheers,
--
Raphaël Hertzog
Reply to: