hey raphael,
On Tue, Sep 29, 2009 at 08:55:56AM +0200, Raphael Hertzog wrote:
> > 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).
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?
> 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)
> 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?
> 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.
> 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.
> > 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.
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.
On Tue, Sep 29, 2009 at 08:19:48AM +0200, Raphael Hertzog wrote:
> On Mon, 28 Sep 2009, Sean Finney wrote:
> > + ohshite(_("unable to stat installed file `%.250s'"), source);
> > + ohshite(_("unable to change ownership of target file`%.250s'"),
> > + target);
> > + ohshite(_("unable to set mode of target file`%.250s'"), target);
>
> We move away from the `' quotes when we have to change strings, we use the
> usual ones (''). You lack a space before the quotes.
okay. i think i copied those verbatim, to avoid fuzzying strings, but
then ended up having to change them anyway since they didn't make sense
in a general context. i'll fix them up in the next version.
btw, this patch series is sitting at the top of the following location:
ssh://git.debian.org/git/users/seanius/dpkg.git
http://git.debian.org/git/users/seanius/dpkg.git
branch: seanius-conffiledb-20090928
and any future revisions i'll put in a similarly timestamped (and rebased)
branch to keep things clean for further review.
sean
--
Attachment:
signature.asc
Description: Digital signature