Re: postinst scripts failing because a new conffile wasn't accepted: Is it a bug?

[Frank Küster <frank@debian.org>]

Henning Makholm <henning@makholm.net> wrote:

> Scripsit Frank Küster <frank@debian.org>
>> Henning Makholm <henning@makholm.net> 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
>> cases.
>
> 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
>>> himself?
>
>> 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).

Regards, Frank

-- 
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer