Re: postinst scripts failing because a new conffile wasn't accepted: Is it a bug?
Henning Makholm <firstname.lastname@example.org> wrote:
> Scripsit Frank Küster <email@example.com>
>> Henning Makholm <firstname.lastname@example.org> wrote:
>>> Do you mean that every package that offers to edit conffiles based on
>>> debconf questions is policy-buggy?
>> Of course, see 10.7.3:
>> | These two styles of configuration file handling must not be mixed, for
>> | that way lies madness: dpkg will ask about overwriting the file every
>> | time the package is upgraded.
> This rationale does not apply to the case we are discussing.
Why do you think that? There are four versions of the conffile that we
have to consider:
1 The version delivered in the old deb
2 The version present on the system before the upgrade
3 The version delivered in the new deb
4 The version produced by the postinst editing action
Right before the postinst is run, version 1 has disappeared, 2 is still
in its place (we are talking about the situation where the admin refused
to accept the changes, and also didn't edit the file), and 3 is
available as *.dpkg-new. The postinst script would remove (or rename)
version 2 and produce version 4. dpgk does not know about this version,
and this is exactly the problem outlined in the policy - or what am I
Inst. f. Biochemie der Univ. Zürich