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 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
