Re: postinst scripts failing because a new conffile wasn't accepted: Is it a bug?
Scripsit Frank Küster <frank@debian.org>
> Henning Makholm <henning@makholm.net> wrote:
>> 4. User selects the "No, I'm happy with my own version as it look
>> now" menu option.
>> Your proposal, if I understand you correctly, is to make (4) result in
>> the postinst failing even though the user _has_ taken care of the problem.
> You must have misunderstood me. I don't check whether the installed
> file is the one I expect; I simply run "fmtutil --all" - and that will
> fail if he hasn't solved the problem.
Ah. I read your proposal as if you wanted to somehow intercept the
user's answer and explicitly bail out from the postinst if the user
"is asked, and he refuses to accept the changed version".
>> Of course it is not a bug if the package fails because the admin does
>> not properly adjust his conffiles.
> So finally there is one person who simply says "yes" to the question in
> the first mail, thank you.
> By the way, I don't think that the answer should be a simple "yes": If a
> failure to configure might cause the system to be inaccessible over the
> net, the package maintainer has to take care to avoid this (i.e. ask a
> non-debconfized question in preinst, as glibc does).
Generally, I think that we depend on the user who has chosen to change
a conffile himself to also be able to judge correctly whether a
maintainer-supplied change is relevant to him or not. Though this
assumption is often wrong, it is the best thing we have in general.
It is of course reasonable to be more paranoid than that in situations
where failure can impair one's ability to fix things later.
In the long run, the user-friendly solution is probably to offer (via
a debconf question that defaults to 'yes') to automatically rewrite
the conffile to take the change into account. In the case you're
presenting here it seems that it ought to be doable by
search-and-replace. The offer should only be made if the conffile has
actually changed *and* it mentions the old variable names *and* one is
upgrading from an older version.
--
Henning Makholm "We can hope that this serious deficiency will be
remedied in the final version of BibTeX, 1.0, which is
expected to appear when the LaTeX 3.0 development is completed."
Reply to: