Re: Bug#777597: perl-modules: upgrade regression: dpkg: dependency problems prevent configuration of perl-modules
On Tue, Feb 10, 2015 at 12:39:36PM +0100, Andreas Beckmann wrote:
> Package: perl-modules
> Version: 5.20.1-5
> Severity: serious
> User: debian-qa@lists.debian.org
> Usertags: piuparts
> Control: affects -1 + libnet-dropbox-api-perl
> Processing triggers for libc-bin (2.19-13) ...
> (Reading database ... 9084 files and directories currently installed.)
> Preparing to unpack .../perl-modules_5.20.1-5_all.deb ...
> Unpacking perl-modules (5.20.1-5) over (5.14.2-21+deb7u2) ...
> dpkg: dependency problems prevent configuration of perl-modules:
> perl-modules depends on perl (>= 5.20.1-1); however:
> Package perl is not configured yet.
> This was observed in wheezy->jessie upgrades of libnet-dropbox-api-perl
> and libwww-mechanize-shell-perl.
>
> All wheezy->jessie upgrade tests had been rescheduled after the perl with
> Breaks and Pre-Depends migrated to testing, but it takes some time to get
> the results ...
I doubt this is actually caused by the perl Breaks/Pre-Depends changes. We
have earlier more or less unreproducible reports of this, at least #766260
and possibly #767734. It's probably just sensitive to the upgrade ordering
so the recent perl changes triggered it again.
It looks like a bug in apt to me. The perl/perl-modules circular dependency
has been around for ages and should be easy to break, but I suppose apt
is trying to configure them in separate dpkg runs or something like that.
If it's actually reproducible this time (I haven't tried yet), that
hopefully helps in understanding the issue. Sven Joachim's analysis in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=767734#10
sounds good, but it doesn't quite fit here as that particular apt bug
shouldn't be present in wheezy (or jessie, for that matter) at all.
Frankly I'm not sure how much we can do about it. Even if it is or will
be fixed in the jessie apt, we have no way to make sure apt gets upgraded
first. We can try to put that in the release notes but that's about it.
(Do we have wheezy->jessie upgrade tests that upgrade apt first?)
Relaxing the circular dependency is a workaround that might be doable,
even though it would be 'incorrect'. There are modules in perl that
need others in perl-modules, and vice versa. However, I count only 21
binary packages in sid [1] that depend on perl-modules but not perl.
As perl is transitively build essential (via dpkg-dev and libdpkg-perl),
build dependencies should not be a concern at all.
So I guess we could still downgrade the perl-modules -> perl dependency to
a recommendation and possibly change those two dozen packages to depend
on perl instead. I'm not thrilled about introducing a possibility for
systems that have perl-modules installed without perl, but I suppose we
could live with it if there's no other way out.
(See #552052 for some background about why we nowadays discourage
direct dependencies on perl-modules.)
Cc'ing Sven, the apt development list, and the debian-perl one.
Any help is welcome.
[1] % grep-dctrl -FDepends perl-modules /var/lib/apt/lists/localhost:3142_debian_dists_unstable_main_binary-amd64_Packages|grep-dctrl -sPackage -n -v -w -FDepends perl
cli-common
cli-common-dev
dhelp
fig2ps
git
iwatch
patcher
perl
polygen-data
pristine-tar
pure-ftpd-common
rinse
shorewall
shorewall-core
snort-common
squid
tvtime
mono-apache-server2
mono-apache-server4
mono-fastcgi-server2
mono-fastcgi-server4
--
Niko Tyni ntyni@debian.org
Reply to: