Re: Better support for merging local and upstream

[Stefan Monnier <monnier@iro.umontreal.ca>]

>> >>> Q: How are we going to do that?
>> >>> A: It's not possible in general.
>> >>
>> >> Of course it is, since you can always fall back on the current code in
>> >> those cases where you don't know how else to do it.
>> >
>> > No, it's not.
>> > Falling back to the old behavior (not merging changes) is not a technique
>> > for automatically merging local changes to conffiles.  It is refusing to
>> > solve the problem, not a solution to the problem.
>> 
>> When an upgrade is installed, local changes *have* to be merged with the
>> changes brought in from the upgrade.  That's just an unvoidable need.

> I disagree with this.  It should be possible to establish "hooks" so
> that the administrator should not ever have to edit an installed file,
> but instead place additional or overriding instructions in a separate
> file which the packages manager would not read or modify.

That's just another name for "automatically merge changes".  Indeed,
Debian already does do such things in some cases e.g. by splitting
/etc/apt.conf into /etc/apt.conf.d/*.
It's still a "merge" conceptually, even if it's spread over several files.

> Even if upstream packaging does not have this capability, Debian-specific
> patches can add it in.

An equivalent change is to leave the code untouched, but define
conventions for how to write those config files, and then use
a specialized tool to merge changes assuming (and/or checking) that the
conventions were followed.

E.g. in the case of /etc/apt.conf you could simply declare that by
convention all config chunks should take the form

  # STARTCHUNK <chunkname>
  <chunk>
  # ENDCHUNK

and then merging changes would work just the same as if the chunks were
each in its own file /etc/apt.conf.d/<chunkname>.

I'm not necessarily advocating this particular convention, just pointing
out that changing the package's source code is not needed because the
same result can be obtained via some other way.

> It would be nice to have a choice of diffing tools, but diff3 and the like
> prefer having 3 copies: "orig", "yours", and "mine".  IIRC, by the time dpkg
> is prompting you, the original conffile is gone.  You've modified the

diff3 doesn't just "prefer" 3 files, it absolutely needs the "orig"
(aka "ancestor").  Keeping this ancestor around is a indeed part of what
I'd like to see.

> Why not write some patches against dpkg and float them out on debian-devel?  

I have my share of work as well, don't you worry,


        Stefan