retitle 501866 dependencies not always installed correctly in prerm/upgrade phase
reassign 501866 dpkg
severity 501866 important
thanks

Le jeudi 16 octobre 2008 Ã* 10:11 +0200, Sven Joachim a écrit :
> On 2008-10-15 17:20 +0200, Josselin Mouette wrote:
> > 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.

OK, doing so.

However we might try to do something to ensure these specific issues
don’t happen during etch->lenny upgrades. Otherwise, we should probably
at least mention this issue in the release notes.

Cheers,
--
.'`.
: :' : We are debian.org. Lower your prices, surrender your code.
`. `' We will add your hardware and software distinctiveness to
`- our own. Resistance is futile.

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.

The fundamental problem here is that perl-modules/perl/perl-base are not
unpacked together. Unless you predepend on perl-modules/perl you can't ensure
that they are in sync. IMO any perl script that is called in a prerm
script should only rely on perl-base and not more.

> > 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.

I don't think this is reasonable. You are asking to change all Depends
into Pre-Depends.

Cheers,
--
Raphaël Hertzog

Le best-seller français mis Ã* jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On Thu, 16 Oct 2008, Raphael Hertzog wrote:
> The fundamental problem here is that perl-modules/perl/perl-base are not
> unpacked together. Unless you predepend on perl-modules/perl you can't ensure
> that they are in sync. IMO any perl script that is called in a prerm
> script should only rely on perl-base and not more.

Random note: A first step to enhance the situation could be to remove the circular dep
between perl and perl-modules. perl should depend on perl-modules and not
the opposite (a conflicts/breaks should forbid the upgrade of perl-modules alone).
That way the configuration and unpack order is less random. But that
doesn't change much for our problem.

Other random remark: in #482140 which seems to have the same root cause the
solution used has been to rely on perl-base only.

Cheers,
--
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

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


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

clone 501866 -1
reassign -1 perl-modules
retitle -1 Circular dependency between perl and perl-modules
thanks

Le jeudi 16 octobre 2008 à 14:33 +0200, Raphael Hertzog a écrit :
> Random note: A first step to enhance the situation could be to remove the circular dep
> between perl and perl-modules. perl should depend on perl-modules and not
> the opposite (a conflicts/breaks should forbid the upgrade of perl-modules alone).
> That way the configuration and unpack order is less random. But that
> doesn't change much for our problem.

Actually, it may be enough to fix the problem. See #316403 for a very
similar issue that was fixed by removing the circular dependency between
libgconf2-4 and gconf.

In all cases, it is a very bad idea to have a circular dependency in
such a core package, and it may trigger similar issues in many cases.
Since there is no real reason for perl-modules to depend on perl, please
use Conflicts to ensure the versions are correct instead.

Thanks,
--
.'`.
: :' : We are debian.org. Lower your prices, surrender your code.
`. `' We will add your hardware and software distinctiveness to
`- our own. Resistance is futile.