Re: Postponing postinst stuff for later execution
uwe@steinmann.cx (Uwe Steinmann) wrote:
> On Wed, Jul 20, 2005 at 08:40:29PM +0200, Frank Küster wrote:
>> uwe@steinmann.cx (Uwe Steinmann) wrote:
>>
>> > On Wed, Jul 20, 2005 at 06:53:32PM +0200, Frank Küster wrote:
>> >
>> >> Do you know whether there have been any cases where a buggy zope package
>> >> caused the restart to fail? And if yes, what will happen (error
>> >> messages, what state are which packages in, and dpkg as a whole)?
>> > I haven't had a case, but from looking at the mechanism used there
>> > aren't many potential points of failure. Each zope extension package
>> > just needs to create a file or not. In the worst case the postinst
>> > script of the zope extension fails to create the file and doesn't
>> > restart zope itself.
>>
>> So the zope case is really simple
> Would the tetex case be more complex? I don't think so.
Yes, it would. First of all, we would need different kind of actions
(run mktexlsr, run update-updmap+updmap-sys, run
update-language+update-fmtutil+fmtutil-sys, and run mktexlsr again. But
the real problem is that fmtutil-sys and updmap are a frequent reason of
failing postinst scripts. Except for last July/August where we made
major rearrangments the cause was always some misconfiguration on the
users' side, but still it failed, and it needed that tetex maintainers
(and not the dpkg maintainers...) to find out why.
Therefore, unless there is a possibility to indicate clearly which
package is responsible, and to get this information again even if no
typescript is available after the first occurrence, it causes me gripes.
Regards, Frank
--
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer
Reply to: