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...@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 nt...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
