Re: [PATCH 6/7] Implement 'm' option for conffile merging during conflict resolution
sean finney wrote:
> On Fri, May 06, 2011 at 03:19:09AM -0500, Jonathan Nieder wrote:
>> In the general case, the right merge result may depend on the content
>> of other files (for example, if the user renamed a file so the new
>> pristine version should be renamed, too). Luckily I don't think the
>> layout is tying our hands, so that could happen in the future.
> I'm not sure I follow you here...
Example: suppose for the sake of example that net-base provides a
complicated conffile called bindv6only.conf under /etc/sysctl.d.
Now suppose I am one of the unfortunate people who uses software that
cannot handle that sysctl, so I move it out of the way, to
Now the net-base maintainer makes a change to the conffile, to fix
a typo in an explanatory comment, maybe. What should happen?
It is possible to imagine the following happening:
- dpkg detects that the file was renamed, perhaps by talking to a
hook script I have set up after placing /etc under version
- dpkg lets me know what happened from its point of view:
I renamed the file, while the net-base maintainer changed it.
- After inspecting the changes, I agree to a merge, and the file
under /etc/sysctl.disabled is updated.
In cases with more semantic information, it is even possible to
imagine the content of one file causing changes to the interpretation
of another file.
All this is to say, it is worth thinking carefully about whether we
are preventing future improvements by using a file layout designed
around dealing with configuration files one at a time. My suspicion
is no, the conffiledb layout is not preventing future improvements
of that kind.
Sorry for a tangent; hoping that is clearer.