Debian Bug report logs - #502455
Circular dependency between perl and perl-modules

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Paul Higgins <paul.higgins@honeywell.com>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: Missing dependancy - libpango1.0-common.prerm uses defoma-app in pkg defoma

Date: Fri, 10 Oct 2008 22:24:49 -0400

Package: libpango1.0-common
Version: 1.20.5-2
Severity: normal


I dusted off a system that hasn't been upgraded since Oct of 2007.

Upgrading it required a big leap in package versions.  The upgrade
of perl, perl-base, and perl-modules caused several problems.
(I'm filing this report for each package involved, as I'm not sure
where the problem is.)

The following excerpts from my upgrade process (and the dpkg.log
excerpt that follows) show all my apparent dependancy problems.  I
suspect that the half-configure / half-install / unpack step for
perl-modules removed the required modules from the
/usr/share/perl/5.8.8 tree.

The prerm  or postrm scripts for these packages use either
/usr/bin/defoma-app or /usr/sbin/install-docs (in packages defoma and
doc-base).  Those in turn reference files in perl-modules already 
removed, causing libtiff4 to abort the install.  In summary:

   fontconfig.prerm, libpango1.prerm, and libwmf0.2-7.postrm
   all invoke /usr/bin/defoma-app; which needs File/Copy.pm
   from perl-modules.  It was able to continue using the prerm
   script from the new package.

   libpng12-0.prerm, libtiff4.prerm, base-passwd.postinst,
   cupsys.prerm, and shared-mime-info.prerm invoke
   /usr/sbin/install-docs which needs Pod/Usage.pm from perl-modules.

I had a backup of the /usr/share/perl/5.8.8 tree, which I reloaded to
aloow me to complete the upgrade.

============ output list from apt-get upgrade, et. al. ========

root@higginsp6:~# apt-get -f dist-upgrade

...

Get: 1172 http://ftp.us.debian.org testing/main udftools 1.0.0b3-14
[77.8kB]
Fetched 1048MB in 1h56m15s (150kB/s)
Extracting templates from packages: 100%
Preconfiguring packages ...

...

Preparing to replace liburi-perl 1.35-2
  (using .../liburi-perl_1.35.dfsg.1-1_all.deb) ...
Unpacking replacement liburi-perl ...
Preparing to replace libhtml-tagset-perl 3.10-2
  (using .../libhtml-tagset-perl_3.20-2_all.deb) ...
Unpacking replacement libhtml-tagset-perl ...
Preparing to replace libhtml-parser-perl 3.56-1
  (using .../libhtml-parser-perl_3.56-1+b1_i386.deb) ...
Unpacking replacement libhtml-parser-perl ...
Preparing to replace sed 4.1.5-2
  (using .../archives/sed_4.1.5-6_i386.deb) ...

...

Preparing to replace libwww-perl 5.805-1
  (using .../libwww-perl_5.813-1_all.deb) ...
Unpacking replacement libwww-perl ...
Preparing to replace perl-modules 5.8.8-7
  (using .../perl-modules_5.10.0-14_all.deb) ...
Unpacking replacement perl-modules ...
Preparing to replace perl 5.8.8-7
  (using .../perl_5.10.0-14_i386.deb) ...
Unpacking replacement perl ...

...

Preparing to replace defoma 0.11.10-0.1
  (using .../defoma_0.11.10-0.2_all.deb) ...
Unpacking replacement defoma ...

...

Preparing to replace fontconfig 2.4.2-1.2
  (using .../fontconfig_2.6.0-1_i386.deb) ...
Can't locate File/Copy.pm in @INC
  (@INC contains: /etc/perl /usr/local/lib/perl/5.8.8
  /usr/local/share/perl/5.8.8 /usr/lib/perl5 /usr/share/perl5
  /usr/lib/perl/5.8 /usr/share/perl/5.8 /usr/local/lib/site_perl .)
  at /usr/bin/defoma-app line 7.
BEGIN failed--compilation aborted at /usr/bin/defoma-app line 7.
dpkg: warning - old pre-removal script returned error exit status 2
dpkg - trying script from the new package instead ...
dpkg: ... it looks like that went OK.
Unpacking replacement fontconfig ...
### fontconfig.prerm invokes /usr/bin/defoma-app
### which needs File/Copy.pm from perl-modules

...

Preparing to replace libpango1.0-common 1.16.4-1
  (using .../libpango1.0-common_1.20.5-2_all.deb) ...
Can't locate File/Copy.pm in @INC
  (@INC contains: /etc/perl /usr/local/lib/perl/5.8.8
  /usr/local/share/perl/5.8.8 /usr/lib/perl5 /usr/share/perl5
  /usr/lib/perl/5.8 /usr/share/perl/5.8 /usr/local/lib/site_perl .)
  at /usr/bin/defoma-app line 7.
BEGIN failed--compilation aborted at /usr/bin/defoma-app line 7.
dpkg: warning - old pre-removal script returned error exit status 2
dpkg - trying script from the new package instead ...
dpkg: ... it looks like that went OK.
### libpango1.prerm invokes /usr/bin/defoma-app
### which needs File/Copy.pm from perl-modules

...

Preparing to replace libpng12-0 1.2.15~beta5-2
  (using .../libpng12-0_1.2.27-1_i386.deb) ...
Can't locate Pod/Usage.pm in @INC
  (@INC contains: /etc/perl /usr/local/lib/perl/5.8.8
  /usr/local/share/perl/5.8.8 /usr/lib/perl5 /usr/share/perl5
  /usr/lib/perl/5.8 /usr/share/perl/5.8 /usr/local/lib/site_perl .)
  at /usr/sbin/install-docs line 18.
Global symbol "$opt_rootdir" requires explicit package name at
  /usr/sbin/install-docs line 126.
Execution of /usr/sbin/install-docs aborted due to compilation errors.
dpkg: warning - old pre-removal script returned error exit status 9
dpkg - trying script from the new package instead ...
dpkg: ... it looks like that went OK.
Unpacking replacement libpng12-0 ...
### libpng12-0.prerm invokes /usr/sbin/install-docs
### which needs Pod/Usage.pm from perl-modules

...

Preparing to replace libwmf0.2-7 0.2.8.4-4
  (using .../libwmf0.2-7_0.2.8.4-6_i386.deb) ...
Can't locate File/Copy.pm in @INC
  (@INC contains: /etc/perl /usr/local/lib/perl/5.8.8
  /usr/local/share/perl/5.8.8 /usr/lib/perl5 /usr/share/perl5
  /usr/lib/perl/5.8 /usr/share/perl/5.8 /usr/local/lib/site_perl .)
  at /usr/bin/defoma-app line 7.
BEGIN failed--compilation aborted at /usr/bin/defoma-app line 7.
dpkg: warning - old pre-removal script returned error exit status 2
dpkg - trying script from the new package instead ...
dpkg: ... it looks like that went OK.
Unpacking replacement libwmf0.2-7 ...
### libwmf0.2-7.postrm invokes /usr/bin/defoma-app
### which needs File/Copy.pm from perl-modules

...

Preparing to replace libtiff4 3.8.2-7
  (using .../libtiff4_3.8.2-11_i386.deb) ...
Can't locate Pod/Usage.pm in @INC
  (@INC contains: /etc/perl /usr/local/lib/perl/5.8.8
  /usr/local/share/perl/5.8.8 /usr/lib/perl5 /usr/share/perl5
  /usr/lib/perl/5.8 /usr/share/perl/5.8 /usr/local/lib/site_perl .)
  at /usr/sbin/install-docs line 18.
Global symbol "$opt_rootdir" requires explicit package name at
  /usr/sbin/install-docs line 126.
Execution of /usr/sbin/install-docs aborted due to compilation errors.
dpkg: warning - old pre-removal script returned error exit status 9
dpkg - trying script from the new package instead ...
dpkg: error processing /var/cache/apt/archives/
                libtiff4_3.8.2-11_i386.deb
  (--unpack):
 there is no script in the new version of the package - giving up
### libtiff4.prerm invokes /usr/sbin/install-docs
### which needs Pod/Usage.pm from perl-modules
### (Note that that the reference to install-docs is moved to
     libtiff-doc somewhere between the old and new versions.)

...

Errors were encountered while processing:
 /var/cache/apt/archives/libtiff4_3.8.2-11_i386.deb
 E: Sub-process /usr/bin/dpkg returned an error code (1)


###  Retried:

higginsp6:~# apt-get -f install
Reading package lists... Done
Building dependency tree... Done
Correcting dependencies...Done

...

Setting up base-passwd (3.5.19) ...
Can't locate Pod/Usage.pm in @INC
  (@INC contains: /etc/perl /usr/local/lib/perl/5.8.8
  /usr/local/share/perl/5.8.8 /usr/lib/perl5 /usr/share/perl5
  /usr/lib/perl/5.8 /usr/share/perl/5.8 /usr/local/lib/site_perl .)
  at /usr/sbin/install-docs line 18.
Global symbol "$opt_rootdir" requires explicit package name at
  /usr/sbin/install-docs line 126.
Execution of /usr/sbin/install-docs aborted due to compilation errors.
dpkg: error processing base-passwd
  (--configure):
 subprocess post-installation script returned error exit status 9
### base-passwd.postinst invokes /usr/sbin/install-docs
### which needs Pod/Usage.pm from perl-modules


###  Retried:

root@higginsp6:~# apt-get -f dist-upgrade
Reading package lists... Done
Building dependency tree... Done
Correcting dependencies...Done
Calculating upgrade... Done

...

Preparing to replace cupsys 1.2.11-2
  (using .../cupsys_1.3.8-1lenny1_all.deb) ...
Can't locate Pod/Usage.pm in @INC
  (@INC contains: /etc/perl /usr/local/lib/perl/5.8.8
  /usr/local/share/perl/5.8.8 /usr/lib/perl5 /usr/share/perl5
  /usr/lib/perl/5.8 /usr/share/perl/5.8 /usr/local/lib/site_perl .)
  at /usr/sbin/install-docs line 18.
Global symbol "$opt_rootdir" requires explicit package name at
  /usr/sbin/install-docs line 126.
Execution of /usr/sbin/install-docs aborted due to compilation errors.
dpkg: warning - old pre-removal script returned error exit status 9
dpkg - trying script from the new package instead ...
dpkg: error processing /var/cache/apt/archives/
                        cupsys_1.3.8-1lenny1_all.deb
  (--unpack):
 there is no script in the new version of the package - giving up
Starting Common Unix Printing System: cupsd.
### cupsys.prerm invokes /usr/sbin/install-docs
### which needs Pod/Usage.pm from perl-modules

...

Preparing to replace shared-mime-info 0.21-2
  (using .../shared-mime-info_0.30-2_i386.deb) ...
Can't locate Pod/Usage.pm in @INC
  (@INC contains: /etc/perl /usr/local/lib/perl/5.8.8
  /usr/local/share/perl/5.8.8 /usr/lib/perl5 /usr/share/perl5
  /usr/lib/perl/5.8 /usr/share/perl/5.8 /usr/local/lib/site_perl .)
  at /usr/sbin/install-docs line 18.
Global symbol "$opt_rootdir" requires explicit package name at
  /usr/sbin/install-docs line 126.
Execution of /usr/sbin/install-docs aborted due to compilation errors.
dpkg: warning - old pre-removal script returned error exit status 9
dpkg - trying script from the new package instead ...
dpkg: ... it looks like that went OK.
### shared-mime-info.prerm invokes /usr/sbin/install-docs
### which needs Pod/Usage.pm from perl-modules


===================================================================
###  dpkg.log except showing perl-modules half-configure /
  half-install / unpack...  and various retries...

2008-10-01 15:59:06 upgrade perl-modules 5.8.8-7 5.10.0-14
2008-10-01 15:59:06 status half-configured perl-modules 5.8.8-7
2008-10-01 15:59:06 status unpacked perl-modules 5.8.8-7
2008-10-01 15:59:06 status half-installed perl-modules 5.8.8-7
2008-10-01 15:59:06 status half-installed perl-modules 5.8.8-7
2008-10-01 15:59:07 status unpacked perl-modules 5.10.0-14
2008-10-01 15:59:07 status unpacked perl-modules 5.10.0-14
2008-10-01 16:00:15 upgrade libtiff4 3.8.2-7 3.8.2-11
2008-10-01 16:00:15 status half-configured libtiff4 3.8.2-7
2008-10-01 16:00:16 status installed libtiff4 3.8.2-7

2008-10-01 17:14:31 upgrade libtiff4 3.8.2-7 3.8.2-11
2008-10-01 17:14:31 status half-configured libtiff4 3.8.2-7
2008-10-01 17:14:31 status installed libtiff4 3.8.2-7

2008-10-01 20:39:31 upgrade libtiff4 3.8.2-7 3.8.2-11
2008-10-01 20:39:31 status half-configured libtiff4 3.8.2-7
2008-10-01 20:39:31 status installed libtiff4 3.8.2-7

2008-10-02 11:20:21 upgrade libtiff4 3.8.2-7 3.8.2-11
2008-10-02 11:20:21 status half-configured libtiff4 3.8.2-7
2008-10-02 11:20:21 status installed libtiff4 3.8.2-7

2008-10-02 14:34:48 upgrade libtiff4 3.8.2-7 3.8.2-11
2008-10-02 14:34:48 status half-configured libtiff4 3.8.2-7
2008-10-02 14:34:48 status installed libtiff4 3.8.2-7

2008-10-02 14:52:49 upgrade libtiff4 3.8.2-7 3.8.2-11
2008-10-02 14:52:49 status half-configured libtiff4 3.8.2-7
2008-10-02 14:52:50 status unpacked libtiff4 3.8.2-7
2008-10-02 14:52:50 status half-installed libtiff4 3.8.2-7
2008-10-02 14:52:50 status half-installed libtiff4 3.8.2-7
2008-10-02 14:52:50 status unpacked libtiff4 3.8.2-11
2008-10-02 14:52:50 status unpacked libtiff4 3.8.2-11
2008-10-02 14:56:16 upgrade perl-base 5.8.8-7 5.10.0-14
2008-10-02 14:56:16 status half-configured perl-base 5.8.8-7
2008-10-02 14:56:16 status unpacked perl-base 5.8.8-7
2008-10-02 14:56:16 status half-installed perl-base 5.8.8-7
2008-10-02 14:56:16 status half-installed perl-base 5.8.8-7
2008-10-02 14:56:16 status unpacked perl-base 5.10.0-14
2008-10-02 14:56:16 status unpacked perl-base 5.10.0-14
2008-10-02 14:56:16 configure perl-base 5.10.0-14 5.10.0-14
2008-10-02 14:56:16 status unpacked perl-base 5.10.0-14
2008-10-02 14:56:16 status half-configured perl-base 5.10.0-14
2008-10-02 14:56:16 status installed perl-base 5.10.0-14
2008-10-02 15:02:21 configure libtiff4 3.8.2-11 3.8.2-11
2008-10-02 15:02:21 status unpacked libtiff4 3.8.2-11
2008-10-02 15:02:21 status half-configured libtiff4 3.8.2-11
2008-10-02 15:02:21 status installed libtiff4 3.8.2-11
2008-10-02 15:43:32 configure perl-modules 5.10.0-14 5.10.0-14
2008-10-02 15:43:32 status unpacked perl-modules 5.10.0-14
2008-10-02 15:43:32 status unpacked perl-modules 5.10.0-14
2008-10-02 15:43:32 status half-configured perl-modules 5.10.0-14
2008-10-02 15:43:32 status installed perl-modules 5.10.0-14


-- System Information:
Debian Release: lenny/sid
  APT prefers testing
  APT policy: (800, 'testing'), (700, 'unstable'), (400, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.26-1-686 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages libpango1.0-common depends on:
ii  debconf [debconf-2.0]        1.5.22      Debian configuration management sy
ii  defoma                       0.11.10-0.2 Debian Font Manager -- automatic f
ii  fontconfig                   2.6.0-1     generic font configuration library

Versions of packages libpango1.0-common recommends:
ii  libpango1.0-0                 1.20.5-2   Layout and rendering of internatio
ii  x-ttcidfont-conf              30         TrueType and CID fonts configurati

Versions of packages libpango1.0-common suggests:
pn  ttf-arphic-bkai00mp           <none>     (no description available)
pn  ttf-arphic-bsmi00lp           <none>     (no description available)
pn  ttf-arphic-gbsn00lp           <none>     (no description available)
pn  ttf-arphic-gkai00mp           <none>     (no description available)
pn  ttf-baekmuk                   <none>     (no description available)
pn  ttf-kochi-gothic              <none>     (no description available)
pn  ttf-kochi-mincho              <none>     (no description available)
pn  ttf-thryomanes                <none>     (no description available)

-- debconf information:
  libpango1.0-common/saved_aliases_file:
  libpango1.0-common/generated_aliases_file:
  libpango1.0-common/use_defoma: true

Message #10 received at 501866@bugs.debian.org (full text, mbox, reply):

From: Josselin Mouette <joss@debian.org>

To: Paul Higgins <paul.higgins@honeywell.com>, 501866@bugs.debian.org

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

Date: Mon, 13 Oct 2008 10:35:45 +0200

[Message part 1 (text/plain, inline)]

Le vendredi 10 octobre 2008 à 22:24 -0400, Paul Higgins a écrit :
> The prerm  or postrm scripts for these packages use either
> /usr/bin/defoma-app or /usr/sbin/install-docs (in packages defoma and
> doc-base).  Those in turn reference files in perl-modules already 
> removed, causing libtiff4 to abort the install.  In summary:
> 
>    fontconfig.prerm, libpango1.prerm, and libwmf0.2-7.postrm
>    all invoke /usr/bin/defoma-app; which needs File/Copy.pm
>    from perl-modules.  It was able to continue using the prerm
>    script from the new package.
> 
>    libpng12-0.prerm, libtiff4.prerm, base-passwd.postinst,
>    cupsys.prerm, and shared-mime-info.prerm invoke
>    /usr/sbin/install-docs which needs Pod/Usage.pm from perl-modules.

What exactly are we supposed to change in those packages? They either
correctly depend on defoma (for defoma-app) or check that install-docs
is here before launching it.

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

[signature.asc (application/pgp-signature, inline)]

Message #15 received at 501866@bugs.debian.org (full text, mbox, reply):

From: "Higgins, Paul" <Paul.Higgins@Honeywell.com>

To: <501866@bugs.debian.org>

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

Date: Wed, 15 Oct 2008 10:37:33 -0400

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.

Paul
-----Original Message-----
From: Josselin Mouette [mailto:joss@debian.org] 
Sent: Monday, October 13, 2008 04:36
To: Higgins, Paul; 501866@bugs.debian.org
Subject: Re: Bug#501866: Missing dependancy - libpango1.0-common.prerm uses defoma-app in pkg defoma

Le vendredi 10 octobre 2008 à 22:24 -0400, Paul Higgins a écrit :
> The prerm  or postrm scripts for these packages use either
> /usr/bin/defoma-app or /usr/sbin/install-docs (in packages defoma and
> doc-base).  Those in turn reference files in perl-modules already 
> removed, causing libtiff4 to abort the install.  In summary:
> 
>    fontconfig.prerm, libpango1.prerm, and libwmf0.2-7.postrm
>    all invoke /usr/bin/defoma-app; which needs File/Copy.pm
>    from perl-modules.  It was able to continue using the prerm
>    script from the new package.
> 
>    libpng12-0.prerm, libtiff4.prerm, base-passwd.postinst,
>    cupsys.prerm, and shared-mime-info.prerm invoke
>    /usr/sbin/install-docs which needs Pod/Usage.pm from perl-modules.

What exactly are we supposed to change in those packages? They either
correctly depend on defoma (for defoma-app) or check that install-docs
is here before launching it.

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

Message #20 received at 501866@bugs.debian.org (full text, mbox, reply):

From: Josselin Mouette <joss@debian.org>

To: "Higgins, Paul" <Paul.Higgins@Honeywell.com>, 501866@bugs.debian.org

Cc: debian-dpkg <debian-dpkg@lists.debian.org>

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

Date: Wed, 15 Oct 2008 17:20:57 +0200

[Message part 1 (text/plain, inline)]

(Please don’t top-post, it’s hard to follow you.)

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. 

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. 

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.

> -----Original Message-----
> From: Josselin Mouette [mailto:joss@debian.org] 
> Sent: Monday, October 13, 2008 04:36
> To: Higgins, Paul; 501866@bugs.debian.org
> Subject: Re: Bug#501866: Missing dependancy - libpango1.0-common.prerm uses defoma-app in pkg defoma
> 
> Le vendredi 10 octobre 2008 à 22:24 -0400, Paul Higgins a écrit :
> > The prerm  or postrm scripts for these packages use either
> > /usr/bin/defoma-app or /usr/sbin/install-docs (in packages defoma and
> > doc-base).  Those in turn reference files in perl-modules already 
> > removed, causing libtiff4 to abort the install.  In summary:
> > 
> >    fontconfig.prerm, libpango1.prerm, and libwmf0.2-7.postrm
> >    all invoke /usr/bin/defoma-app; which needs File/Copy.pm
> >    from perl-modules.  It was able to continue using the prerm
> >    script from the new package.
> > 
> >    libpng12-0.prerm, libtiff4.prerm, base-passwd.postinst,
> >    cupsys.prerm, and shared-mime-info.prerm invoke
> >    /usr/sbin/install-docs which needs Pod/Usage.pm from perl-modules.
> 
> What exactly are we supposed to change in those packages? They either
> correctly depend on defoma (for defoma-app) or check that install-docs
> is here before launching it.

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

[signature.asc (application/pgp-signature, inline)]

Message #25 received at 501866@bugs.debian.org (full text, mbox, reply):

From: Sven Joachim <svenjoac@gmx.de>

To: Josselin Mouette <joss@debian.org>

Cc: "Higgins\, Paul" <Paul.Higgins@Honeywell.com>, 501866@bugs.debian.org, debian-dpkg <debian-dpkg@lists.debian.org>

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

Date: Thu, 16 Oct 2008 10:11:09 +0200

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

Message #30 received at 501866@bugs.debian.org (full text, mbox, reply):

From: Josselin Mouette <joss@debian.org>

To: Sven Joachim <svenjoac@gmx.de>

Cc: "Higgins, Paul" <Paul.Higgins@Honeywell.com>, 501866@bugs.debian.org, debian-dpkg <debian-dpkg@lists.debian.org>

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

Date: Thu, 16 Oct 2008 11:01:50 +0200

[Message part 1 (text/plain, inline)]

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.

[signature.asc (application/pgp-signature, inline)]

Message #41 received at 501866@bugs.debian.org (full text, mbox, reply):

From: Raphael Hertzog <hertzog@debian.org>

To: Josselin Mouette <joss@debian.org>, "Higgins, Paul" <Paul.Higgins@Honeywell.com>, 501866@bugs.debian.org, debian-dpkg <debian-dpkg@lists.debian.org>

Cc: perl@packages.debian.org

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

Date: Thu, 16 Oct 2008 13:35:42 +0200

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/

Message #46 received at 501866@bugs.debian.org (full text, mbox, reply):

From: Raphael Hertzog <hertzog@debian.org>

To: Josselin Mouette <joss@debian.org>, "Higgins, Paul" <Paul.Higgins@Honeywell.com>, 501866@bugs.debian.org, debian-dpkg <debian-dpkg@lists.debian.org>, perl@packages.debian.org

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

Date: Thu, 16 Oct 2008 14:33:01 +0200

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/

Message #51 received at 501866@bugs.debian.org (full text, mbox, reply):

From: Sven Joachim <svenjoac@gmx.de>

To: Josselin Mouette <joss@debian.org>

Cc: "Higgins\, Paul" <Paul.Higgins@Honeywell.com>, 501866@bugs.debian.org, debian-dpkg <debian-dpkg@lists.debian.org>, perl@packages.debian.org

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

Date: Thu, 16 Oct 2008 16:14:49 +0200

On 2008-10-16 13:35 +0200, Raphael Hertzog wrote:

> On Thu, 16 Oct 2008, Sven Joachim wrote:
>> 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.
>
> 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.

If this is not going to change, it should be documented in the Policy.

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

Not quite, since prerm scripts are only called during removals and
upgrades, and if the package being removed or upgraded had been
installed correctly, the dependencies should be fulfilled during the run
of the prerm script.  However, this cannot be guaranteed in all cases,
e.g. if there are circular dependencies.

Sven

Message #56 received at 501866@bugs.debian.org (full text, mbox, reply):

From: Kurt Roeckx <kurt@roeckx.be>

To: Josselin Mouette <joss@debian.org>, "Higgins, Paul" <Paul.Higgins@Honeywell.com>, 501866@bugs.debian.org, debian-dpkg <debian-dpkg@lists.debian.org>, perl@packages.debian.org

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

Date: Thu, 16 Oct 2008 18:28:23 +0200

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

Message #61 received at 501866@bugs.debian.org (full text, mbox, reply):

From: Josselin Mouette <joss@debian.org>

To: Raphael Hertzog <hertzog@debian.org>

Cc: "Higgins, Paul" <Paul.Higgins@Honeywell.com>, 501866@bugs.debian.org, debian-dpkg <debian-dpkg@lists.debian.org>, perl@packages.debian.org

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

Date: Thu, 16 Oct 2008 18:38:20 +0200

[Message part 1 (text/plain, inline)]

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.

[signature.asc (application/pgp-signature, inline)]

Message #72 received at 502455@bugs.debian.org (full text, mbox, reply):

From: Niko Tyni <ntyni@debian.org>

To: Josselin Mouette <joss@debian.org>

Cc: "Higgins, Paul" <Paul.Higgins@Honeywell.com>, 502455@bugs.debian.org, debian-dpkg <debian-dpkg@lists.debian.org>

Subject: Re: Bug#502455: Circular dependency between perl and perl-modules

Date: Fri, 17 Oct 2008 15:37:55 +0300

On Thu, Oct 16, 2008 at 06:38:20PM +0200, Josselin Mouette wrote:
> 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.

Even with perl-modules conflicting on older versions of perl (or
perl-base for that matter), it's possible for the perl packages to
get out of sync the other way: if a newer perl-base is unpacked first,
it can't find the modules in perl or perl-modules.

As far as I understand, with or without circular dependencies the only
packages that are guaranteed to work from 'old-prerm upgrade' are the
Essential:yes ones and those that are Pre-Depended on by the new version
of the package. (Yes, the policy could be clearer about this).

See also #495359 and #482140.

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

I'm not familiar with the origins of the circular dependency, but it's
been there since at least 2001 or so and was probably last touched
in 5.6.1-5. Changing it at this stage of the release cycle seems risky,
particularly as I don't think it would even solve the original problem.

(After Lenny, I suppose Breaks: would be useful for this.)
-- 
Niko Tyni   ntyni@debian.org

Message #79 received at 502455-close@bugs.debian.org (full text, mbox, reply):

From: Dominic Hargreaves <dom@earth.li>

To: 502455-close@bugs.debian.org

Subject: Bug#502455: fixed in perl 5.20.2-1

Date: Fri, 27 Feb 2015 18:36:21 +0000

Source: perl
Source-Version: 5.20.2-1

We believe that the bug you reported is fixed in the latest version of
perl, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 502455@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Dominic Hargreaves <dom@earth.li> (supplier of updated perl package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.8
Date: Fri, 27 Feb 2015 17:48:02 +0000
Source: perl
Binary: perl-base perl-doc perl-debug libperl5.20 libperl-dev perl-modules perl
Architecture: all amd64 source
Version: 5.20.2-1
Distribution: unstable
Urgency: medium
Maintainer: Niko Tyni <ntyni@debian.org>
Changed-By: Dominic Hargreaves <dom@earth.li>
Closes: 502455 777597
Description: 
 libperl5.20 - shared Perl library
 libperl-dev - Perl library: development files
 perl-base  - minimal Perl system
 perl-debug - debug-enabled Perl interpreter
 perl-doc   - Perl documentation
 perl       - Larry Wall's Practical Extraction and Report Language
 perl-modules - Core Perl modules
Changes:
 perl (5.20.2-1) unstable; urgency=medium
 .
   * New upstream release
   * Update Breaks versions for libfile-spec-perl, libmodule-corelist-perl,
     libstorable-perl
   * Break circular dependency between perl and perl-modules
     (Closes: #777597, #502455)
   * Add Breaks: entries for various packages which could be affected by
     the above change, where they have been fixed
Checksums-Sha1: 
 9277e0989b3e37fdbea5416f782d4bfc4d3d035a 2294 perl_5.20.2-1.dsc
 63126c683b4c79c35008a47d56f7beae876c569f 13717128 perl_5.20.2.orig.tar.bz2
 38bdb9ebbd911f3b3f552bdba6ec388c2536b267 103440 perl_5.20.2-1.debian.tar.xz
 ca0752049a11ad8042d57fd53d586c498292d97d 7343118 perl-doc_5.20.2-1_all.deb
 b13597ec7791768816943bc63713008a89b2a6f1 2545698 perl-modules_5.20.2-1_all.deb
 a1c96c6b93cb6bb2e8525006c5668ecdc816cb0d 1223812 perl-base_5.20.2-1_amd64.deb
 f3c53bd1d31c196f739604d6197e7d9fc125f54c 4631150 perl-debug_5.20.2-1_amd64.deb
 2e0b5ca78339e69c6d220c21c523a0db38d1963e 1348 libperl5.20_5.20.2-1_amd64.deb
 ea994033cadc50d5404727a154cbc02b5b69a52a 2149634 libperl-dev_5.20.2-1_amd64.deb
 03650a1f15757b66f905b3f0757c67f5bd39507a 2647534 perl_5.20.2-1_amd64.deb
Checksums-Sha256: 
 bcd53200d76e5faa0567f403b1d9c9bb1055d1a895c4b861d8658e3bb1e3533d 2294 perl_5.20.2-1.dsc
 e5a4713bc65e1da98ebd833dce425c000768bfe84d17ec5183ec5ca249db71ab 13717128 perl_5.20.2.orig.tar.bz2
 86d165a1f584c4c3299deab9d37758f55610d0f38069591eb78936fad26f20c3 103440 perl_5.20.2-1.debian.tar.xz
 cf1180601079f51f20fb38a636f28e4f234544832258d7efce16c40ec2317ff7 7343118 perl-doc_5.20.2-1_all.deb
 9828b68ab1d3be7bc171ca082c283b91a2930599b5e6f8849045861d55551df5 2545698 perl-modules_5.20.2-1_all.deb
 f00b0249057c515d21226b6f69312138b1d85a57274f54f6b5ac559ec134c0c2 1223812 perl-base_5.20.2-1_amd64.deb
 8b47a63d1a7f462847405e1aa85cd912afa65822cebd2fe15f12ca8ba0225ed7 4631150 perl-debug_5.20.2-1_amd64.deb
 244a77667999c7352abfa5eeb92dba4bc96cb47b3542c811cc73e3930a497deb 1348 libperl5.20_5.20.2-1_amd64.deb
 5d61291bb3900a2d8573e298a1c0149ef0ced42613b8813e0e0a1f31fbfe49ba 2149634 libperl-dev_5.20.2-1_amd64.deb
 6509d599813d3ed78770351ad2d5614960c2ab4263a89bd3e3a797aa046fdad8 2647534 perl_5.20.2-1_amd64.deb
Files: 
 63f17687c3a7546218f7395f57978f5d 2294 perl standard perl_5.20.2-1.dsc
 21062666f1c627aeb6dbff3c6952738b 13717128 perl standard perl_5.20.2.orig.tar.bz2
 953f3afcd47d96ac24611ca4ba7af813 103440 perl standard perl_5.20.2-1.debian.tar.xz
 6293f7955e57e8dca690f8b30334b59b 7343118 doc optional perl-doc_5.20.2-1_all.deb
 115ff3ca2ae3d5a4a9f724bf812e03b8 2545698 perl standard perl-modules_5.20.2-1_all.deb
 1cabe219c97e711b7b587f2cb6a581bd 1223812 perl required perl-base_5.20.2-1_amd64.deb
 eea82ed13a27fe7b0607c7bf1cb33887 4631150 debug extra perl-debug_5.20.2-1_amd64.deb
 bafc07e324116c9b93e3724270c4951c 1348 libs optional libperl5.20_5.20.2-1_amd64.deb
 a021591e0a53edf8a0feb00d8dc605e4 2149634 libdevel optional libperl-dev_5.20.2-1_amd64.deb
 4aca1883d9d8a05548ed03479cdefa10 2647534 perl standard perl_5.20.2-1_amd64.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJU8LbYAAoJEMAFfnFNaU+yZngP/1f5UwhVYKM7QeJF0JZWyVsp
GALFp2HLY7eGfPwsPgf/x/hrfrgaYPLYukOyl390iZQ+/vehktdU/qZ06ABIZQhQ
iB41d0ne8ChNj5+gbgoupRZaQlmKHJMJqw9KlftVmt4TSLW8X9gc6/fWPkYNHNMF
4MrkdzabNwe9EGbS6zqDi1977rTOqCiuSIyZVJtv8l34+ENR9sfl10ie71NkCgC+
g1j+gPpR0FvuEaSb3SIVQss85tENk0znBk1VLCEXmwjn5WU8AuczfPK7EZ5MCJKo
iWlpcRDWjAZUfEXaN4GFX/54xjAh4hjgrAm7blDrVJZvGgwfBHRLI+BAUQ+PVeV6
/sCEaoDXvybEXPOwJXKB4uk5eJZ+g9BXMMK5najPzefoZN048xyidwUVNCrVP8cZ
M6bVYXpXDfBQzXB387cuEV0s3cHznahkPPi8q5w7CpJLBOrjEBhXY1sz3UQQeio2
qzIT7AaYu8OLnrCnnWG3XwRTjLEz2abFVkSbgZkyiNtd82+fMEjkjvLz03V0BA7W
aYs6lfUt0sNPzm2NWP+CkKbNVeemX4p9cwP/2ZgCUh5/9paahymlPUBWsmW1Leqc
KkN3s6fZFoWSYaLy4D9OODX7sxjB4ZyUykT2Nsp7NG7DXjscNDMAU0cpVGpzTmST
qxjFk481cxfBd3khMvvf
=x2SF
-----END PGP SIGNATURE-----

Send a report that this bug log contains spam.