Re: Bug#501866: Missing dependancy - libpango1.0-common.prerm uses defoma-app in pkg defoma
On Thu, Oct 16, 2008 at 01:35:42PM +0200, Raphael Hertzog wrote:
> On Thu, 16 Oct 2008, Sven Joachim wrote:
> > 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.
>
> I'm not quite sure this is the right thing to do, quoting policy:
> A Depends field takes effect only when a package is to be configured. It
> does not prevent a package being on the system in an unconfigured state
> while its dependencies are unsatisfied, and it is possible to replace a
> package whose dependencies are satisfied and which is properly
> installed with a different version whose dependencies are not and
> cannot be satisfied;
>
> So there's no guaranty in the prerm script. You can only rely on essential
> packages being unpacked.
There is also this in policy:
`Depends'
This declares an absolute dependency. A package will not be
configured unless all of the packages listed in its `Depends'
field have been correctly configured.
The `Depends' field should be used if the depended-on package is
required for the depending package to provide a significant
amount of functionality.
The `Depends' field should also be used if the `postinst',
`prerm' or `postrm' scripts require the package to be present in
order to run. Note, however, that the `postrm' cannot rely on
any non-essential packages to be present during the `purge'
phase.
At first sight this seem to conflict, but note that it says present
and not unpacked or configured. I think there is some bug open
against policy about it, but can't find it right now. I think many
people atleast interprete it as configured, while it should probably
say unpacked.
It also says:
In case of circular dependencies, since installation or removal order
honoring the dependency order can't be established, dependency loops
are broken at some point (based on rules below), and some packages may
not be able to rely on their dependencies being present when being
installed or removed, depending on which side of the break of the
circular dependency loop they happen to be on. If one of the packages
in the loop has no postinst script, then the cycle will be broken at
that package, so as to ensure that all postinst scripts run with the
dependencies properly configured if this is possible. Otherwise the
breaking point is arbitrary.
Maybe it should also take the prerm scripts into account (on upgrade)?
Note sure if this helps at all in this case.
Kurt
Reply to: