hi bruno,
wow, looks like you spent some time thinking about this :)
i hope you don't mind, but i'm going to forward much of this on to the
dpkg developers list.
On Thu, Feb 26, 2009 at 11:01:31AM +0100, Bruno De Fraine wrote:
> http://lists.debian.org/debian-dpkg/2008/04/msg00022.html
> http://wiki.debian.org/Teams/Dpkg/Proposals/ConffileDatabase
>
> Could you tell me whether the status of your work changed since these
> reports? You talk about a current implementation of the hash-based
> database, is that available in your git branch? Is is up to date for
> dpkg 1.14.25?
it hasn't afaik. i lost interest in pushing for something that didn't
seem to keep much interest on the dpkg developer side. this was also
around the time of all the hijack/triggers bad blood, so i didn't want
to antagonize the maintainers more than they were already dealing with;
i just told the relevant maintainer to get back to me when he had the
time and he never did.
i believe the hash implementation is also in the git repo, i forget at
this point which one i settled on.
> In any case, I have one remark about your proposal. I don't think dpkg
> should simply track the unmodified conffile of currently installed
> version of a package. Rather, I think it should track the "base" version
> of the conffile that is currently employed. Concretely, this means that
> when dpkg installs a new version of the conffile without modifications,
> it should store this new version as the base version. Similarly, when a
> new version of the conffile is merged with existing changes then the
> base version is updated to new version of the conffile from the
> maintainer. However, in the case where the package is updated but the
> user keeps his local version ('N'), the base version stays the same. As
> such, the user's local changes can always be determined by looking at
> the delta between the base version and the employed version. This is
> similar to what version control systems do.
that's an interesting point. if i understand you correctly, i suppose
it would keep potentially complicated merges simpler in future merges,
by updating the "parent" of the three way merge. correct? in that case
i'd advocate for keeping both, and making the behaviour to try to take the
"recent merge" first, and if there is none, try the "pristine version" second,
which would be a general recipe for all cases.
> > resolving which database implementation should be used
>
> I'm leaning towards the path-based layout. As you explain, there is
> also a risk of running into the PATH_MAX limit when building in a home
> dir (of course dpkg should check this limit). And the hash based version
> has always the risk of a hash collision (also highly unlikely, but not
> impossible).
i'm still fairly ambivalent about this. i honestly don't think either way
is incredibly bad. the biggest detractor is the increased likelihood
of people poking around where they shouldn't, but on the bright side it
makes a simpler implementation i guess.
> > for merging should we attempt the merge first, and then display the
> > option if we know it's possible?
>
> I've given this some thought and I think the concrete interface should
> work as follows:
>
> 1. dpkg should be configurable with a diff3-tool. This can be the
> standard diff3 from the 'diff' package or a tool with the same
> interface. I think diff3 is more or less a standard interface, for
> example, Subversion also allows you to configure a diff3-cmd. Many
> interactive merge tools should have a wrapper that allows them to be
> used like diff3.
>
> 2. When dpkg detects that the conffile has local changes and there is a
> new maintainer version, it will present the Y/N/I/D menu. If it detects
> a base version and it has a diff3 tool available then there should be a
> merge (M) option.
yes, w.r.t. (2), this is what it currently does, though diff3 is hard-coded.
> 3. When the user selects this merge option, then dpkg will invoke
>
> $DIFF3 -m $LOCAL $BASE $NEW > $LOCAL.dpkg-merge
>
> 3.a) If the diff3 exit code indicates no conflicts, then the
> $LOCAL.dpkg-merge file can be moved to $LOCAL (perhaps after first moving
> $LOCAL to $LOCAL.dpkg-old). dpkg can continue without further
> interaction.
>
> 3.b) If the diff3 exit code indicates conflicts, then the user is
> informed of this outcome and the menu is repeated. The user has the
> option of exiting to the shell, where he can inspect the
> $LOCAL.dpkg-merge file, fix the conflicts, and move it into place. (The
> standard diff3 behavior is to indicate conflicts in the merge file using
> bracketing, which still makes it very easy to resolve conflicts.) He
> still has the option to fall back to his $LOCAL file ('D') or the $NEW
> file ('I').
>
> 4. dpkg will update the base version of the conffile according to the
> outcome of the menu. In case of an 'I' or a successful 'M', $NEW
> becomes $BASE. In case of a 'D', $BASE is not updated. One remark here
> is that if the user manually installed $LOCAL.dpkg-merge, then we should
> update the $BASE as well. There should be some protocol to determine if
> the user considered his manual interaction a successful merge or not.
>
> > for non-automatic merges could we do something like git mergetool?
>
> I don't know exactly about git mergetool, but the interesting bit of the
> above scheme is that $DIFF3 may be an interactive or GUI program
> (although unfortunately, it may not employ STDOUT to communicate with
> the user, since STDOUT will receive the result of the merge).
>
> When there is a conflict, the $DIFF3 can immediately prompt the user for
> input on how to resolve the conflict. As such, even merges with
> conflicts can be carried out with minimal effort from the user.
>
> (I've previously written a wrapper scripts to employ a GUI tool on
> MacOSX as a diff3-cmd with Subversion, this works quite well, see
> http://ssel.vub.ac.be/ssel/internal:fmdiff )
>
> As you may see, I have a quite concrete view of how this could work.
> However, these are merely suggestions. Feel free to provide your opinion
> of how this could best be handled and what has already been done.
thanks for all the feedback.
sean
--
Attachment:
signature.asc
Description: Digital signature