Re: postinst scripts failing because a new conffile wasn't accepted: Is it a bug?
> assume that an update to a package brings in a changed conffile, and
> because the local admin had changed the conffile, he is asked, and he
> refuses to accept the changed version.
This brings up an issue that is bothering me as a user since a long
time. Whenever I change a config file, I have to take care and examine
changes of the config file in its pacakge. Because most times those
provide some enhancments (e.g. commented out proposals for new options
available), mostly it is a good idea to merge the changes into my own
config. Currently I have to do this merge by hand. However it would be
much smarter to have an option [M]erge when configuring, allowing to
merge the changes into the the local config file . (Of course there
should be also something like: "preview merge" and "preview diff merge
with current config").
I know this is a little bit tricky, because it requires the old versions
of the config files to be available, and therefore requires a change in
the package system (keeping the old config files in a seperate location
Now I have two questions: Is such a feature generally desirable? Is
there someone willing to give it some thought and implement it (I am
currently short in time) or should I file a wishlist bug against dpkg?
I think having an option "Merge" is far better than just to keep the old
file. New vital changes would be propagated to the administrators
conffiles. Problems would only occur when conflicts appear (detectable),
or if the maintainer uses a deprecated option (not detectable, but
happens with the current solution too).
 I'm thinking of something similar to CVS/SVN merge here
Please do not sent any email to the email@example.com - all email not
originating from the mailing list will be deleted automatically. Use the
reply to address instead.