On Thu, Feb 26, 2009 at 07:07:30PM +0100, sean finney wrote:
> On Thu, Feb 26, 2009 at 09:14:23AM +0100, Stefano Zacchiroli wrote:
> > Well, it depends on how dpkg currently handles merges. My impression
> > (as a user, never looked at the actual code) is that it not even tries
> > to merge, it simply discovers that the local file is not pristine and
> > then asks the user. On the contrary, every VCS I'm aware of at least
> > _tries_ a merge, "succeeding" when changes do not affect the same
> > patch hunk.
>
> it can't do a merge currently, because it doesn't have the common
> ancestor available to do a 3-way diff.
Yes, that's clear. In fact my idea (actually, more of a flux of
thoughts) was to externalize that information, as in:
- dpkg discovers a change (and it can do that using plain old
checksums as it currently does)
- it checks whether there is an hook registered to do that
- if so, it invokes it by passing (API totally approximated) the
path of the current conffile, the version of the package owning it
which is being removed, the path of the new file
- it is now up to the hook to be able to retrieve the old file, which
a VCS in someway can be able to do [*]
then you have different ways for the hook to return, such as:
- 0: yay, everything merged -> continue without bothering the user
- 1: don't know what to do (e.g., I cannot retrieve the old file)
-> fallback to the current behavior or try some other hook
- 2: merge failure -> offer the change to revert and fallback, or
maybe to examine the conflict as we usually do with VCSs
[*] Now that you make me think about it however, it would be perfectly
plausible to request dpkg to store under /var/lib/dpkg/info/ all
pristine copies of configuration files, instead of only their
checksums (I doubt the space consumption would be significant). If
that is acceptable, you can pass the hook the actual path to the
old pristine conffile without requesting the hook to be able to
retrieve it. YMMV.
> > Of course that would mean that dpkg should be made aware of the
> > difference between the last pristine configuration file installed
> > on the machine, and the configuration file the package being
> > installed is shipping.
>
> if you go about a year back or so in the dpkg-mailing lists/bts (or
> look in the debian wiki, there's references there somewhere) you'll
> see some stuff i proposed--including a working patch. unfortunately
> this never seemed to amount to much and didn't keep the interest of
> the relevant dpkg maintainer.
Can you please give some tiny teeny details about what strategy did
you implement? In this thread, and from your mail, I don't get yet
which approach you could possibly have taken ..., but thanks for the
heads up!
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...........| ..: |.... Je dis tu à tous ceux que j'aime
Attachment:
signature.asc
Description: Digital signature