Re: postinst scripts failing because a new conffile wasn't accepted: Is it a bug?
Henning Makholm <email@example.com> wrote:
> Scripsit Frank Küster <firstname.lastname@example.org>
>> Henning Makholm <email@example.com> wrote:
>>> You seem to assume that the *only* way to get this change into the
>>> file is to forcibly discard all of the sysadmin's local adaptations
>>> and install a pristine upstream version of the conffile.
>> No, of course there is an other way: dpkg offers an option to start a
>> shell (or put itself in the background or whatever) to clear up the
>> situation; or one can simply log in on a different terminal.
> Exactly, but what happens then is
> 1. User backgrounds dpkg, or switches to another window.
> 2. User edits the file to take into account the new variable name.
> 3. User returns to dpkg.
> 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.
>> But if the local admin doesn't want to do that, but delay merging
>> the configuration file, there are only two possibilities: Either he
>> accepts the new maintainer's version, or he refuses it. And the
>> latter choice leads to a failure of the postinst script in some
> This is not true.
It is - with "that" I meant to edit the file now.
> If he edits the file himself (but refuses the
> maintainer's version because accepting it would lead to his own
> changes being overwritten) things still work fine.
Of course they will. In particular, I won't get a bug report and won't
have to consider closing or downgrading it, and ask questions on -devel
>>> Why do you want to deny the sysadmin the opportunity to do the changes
>> I don't.
> You want the postinst to fail if he does the changes himself rather
> than abandoning all of his local changes, right?
No, if I have written something like this I must have been insane. All
I want to say is: If he does the changes himself bug does it wrong, the
fmtutil call (or updmap or whatever) in postinst will fail.
But this is in fact a corner case, the usual situation is that the user
pressed "keep local version" without thinking, or simply uses the
noninteractive frontend and doesn't bother himself with looking at any
*.dpkg-new files before reporting the bug.
>> All I do is request some support for the view that if he decides to
>> do so, he should in fact do it before filing a bug;
> 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).
Inst. f. Biochemie der Univ. Zürich