Bug#501866: Missing dependancy - libpango1.0-common.prerm uses defoma-app in pkg defoma

[Sven Joachim]

On 2008-10-15 17:20 +0200, Josselin Mouette wrote:

> Le mercredi 15 octobre 2008 à 10:37 -0400, Higgins, Paul a écrit :
>> I'm not sure where the problem lies.  I saw that the packages that
>> couldn't find File/Copy.pm seemed to have their dependencies correct,
>> but apt and dpkg still allowed perl-modules to break it.  The one
>> package I checked closely because it broke the install, libtiff4,
>> doesn't seem to depend on doc-base as it should.  
>> 
>> It seems like there must be some way to make sure the unpack, etc. for
>> package perl-modules 5.10.x either leaves the 5.8.x tree alone, or
>> waits until it is no longer needed to remove it.
>
> Frankly, I’m tempted to reassign this to dpkg; Policy §7.2 is very clear
> on the relationship between prerm scripts and Depends. 

I think reassigning would be OK.  Maybe also raising the severity to
important.

> It’s not the first time I’ve seen this, although it usually happens when
> there is a dependency cycle: one of the dependencies of a package in the
> Depends list can be in a broken state at the time of prerm running. 

This happens during upgrades because the dependencies are not checked
during unpacking; dpkg unpacks the packages in the order given on the
commandline.

> Dpkg needs to ensure that all dependencies *and their own dependencies*
> are in a clean, installed state when running the prerm script. It
> correctly does it for postinst already.

It also does it for the prerm when removing packages, but not during
upgrades.  This is what caused the originally reported problem (perl was
unpacked first, then libpango1.0-common).

Note, however, that both the old and the new prerm script may be called
during upgrades (in case the former fails, see Policy §6.6) and it might
not be possible to fulfill the dependencies of both the new and the old
package.

Sven