Re: postinst scripts failing because a new conffile wasn't accepted: Is it a bug?
Frank Lichtenheld <djpig@debian.org> wrote:
> On Mon, Oct 31, 2005 at 06:56:44PM +0100, Frank Küster wrote:
>> In my opinion this is not a bug (except if the package is crucial for
>> the system to work and be reachable, like ssh) - the local admin simply
>> has to review the changes to conffiles that dpkg requested, and have a
>> look at NEWS.Debian and changelog.Debian. If these files do not contain
>> enough information to fix the system, then this is a bug, right? But
>> the simple fact that a postinst script fails because a change has been
>> refused isn't - and for sure it is not a serious or grave bug,
>> severities often used when a postinst fails.
>>
>> Opinions?
>
> There is one big problem with that scenario that I haven't seen
> mentioned in this thread yet: If I make the dist-upgrade of a machine
> from sarge to etch and the dist-upgrade fails right in the middle
> of the installed 3000 packages I will be severly disappointed to
> say the least if that didn't happen for a very good reason...
> That's a fact that often gets lost when discussing such problem from
> developer to developer that install sid on their machines and update
> about 30 packages at once.
Maybe we need a policy (or a change in dpkg's default behavior) for
that. One option would be to recommend to take the new version and
merge local changes afterwards (but this might severely break more
important things, like ssh in an environment where port 22 is
blocked...). Or on the other hand, packages that change incompatibly
must ensure that they are not installed automatically - however that
would mean that every package that build-depends on the changed package
would have to change its control file.
> So if it is at all possible to avoid failing the postinst (which of
> course also means to not break other packages installation as you
> have pointed out) it should be done.
>
> If it is at all possible in the case of tetex I can't tell, though.
I do not see how it could be made possible. Oh, yes, there is one way,
and we have even tried to go that route: After the conffile questions
have been asked, we check in the postinst script whether some essential
entries in ucf-managed configuration files are wrong, and if they are we
change the file. But we can't do that for dpkg-managed files, and in
any case I don't want to have a 1000 line postinst script because it
checks for 30 possibly fatal refused changes...
Regards, Frank
--
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer
Reply to: