On Fri, Aug 30, 2013 at 08:28:00PM +0200, Axel Beckert wrote: > Package: perl > Version: 5.18.1-2 > Severity: serious > as discussed with Dom, Niko and Jonas on #debian-perl: > > The Perl 5.18 upgrade on one of my boxes (kfreebsd-i386, cdebconf, > tons of devel and desktop packages installed) went bad because > libscalar-list-utils-perl should have been upgraded earlier. (Niko > Tyni mentioned that this is probablu there since 1.23_03 -- which > dropped the fallback to pure perl versions.)
> Setting up man-db (2.6.5-2) ... > Can't load '/usr/lib/perl5/auto/List/Util/Util.so' for module List::Util: > /usr/lib/perl5/auto/List/Util/Util.so: undefined symbol: Perl_gv_init at > /usr/share/perl/5.18/XSLoader.pm line 68. at /usr/lib/perl5/List/Util.pm line 21. > Compilation failed in require at /usr/lib/perl5/Scalar/Util.pm line 11. [...] > Compilation failed in require at /usr/share/debconf/frontend line 6. > BEGIN failed--compilation aborted at /usr/share/debconf/frontend line 6. > dpkg: error processing man-db (--configure): > subprocess installed post-installation script returned error exit status 255 Thanks for the report. The problem of course is that libscalar-list-utils-perl is overriding Essential:yes functionality in perl-base in a way that breaks when perl-base is upgraded. I think the reason this hasn't bitten us in previous Perl transitions is because the module used to fall back to a pure Perl version when the XS version failed to load. FWIW I suspect that libsocket-perl is affected too, but I'm guessing no maintainer scripts need it so that's "just" a latent bug. My first thought was that a bandaid fix for libscalar-list-utils-perl would be for the new perl-base to Conflict with libscalar-list-utils-perl (<= 1:1.27-1): the packages built against Perl 5.18 are all versioned at 1:1.27-1+b1. (This is somewhat ugly as it's specific to Debian binNMU versioning and would mean that we'd hit this again in future transitions.) However, that's not enough on its own: the same breakage happens if the 5.18 build of libscalar-list-utils-perl is unpacked before perl-base is upgraded, The only working upgrade solution is to temporarily remove libscalar-list-utils-perl, and I don't think apt does that. Indeed, throwing in an additional trial version of libscalar-list-utils-perl that Pre-Depends on perl-base + perlapi-5.18.1 makes apt go in a wild loop and eventually segfault. (Not entirely surprising as this and the above Conflict form a pre-dependency loop.) One idea I entertained briefly is patching libscalar-list-utils-perl to traverse @INC and try to load other available versions of Util.so if the first one fails. However, that would mean a version discrepancy when the Perl wrapper would be from libscalar-list-utils-perl and the XS code from the older perl-base version. This doesn't seem particularly robust. So, we may need to either forbid separately packaged versions of modules in perl-base, or implement a separate versioned directory for them instead of /usr/lib/perl5. The latter is not a simple matter and needs a full discussion on the policy list. Other ideas are welcome of course. Meanwhile, I don't think this is quite so critical that it warrants a hurried upload, as systems with libscalar-list-utils-perl installed are probably quite uncommon. The only versioned reverse dependencies are librdf-trine-perl libscalar-does-perl libtest-rdf-perl If no good solution is found, I guess we'll need to upload perl with an unversioned conflict on libscalar-list-utils-perl, which would render the above packages and their reverse dependencies uninstallable. Maybe someone could investigate why the above packages need a newer version in the first place and whether that could be worked around somehow? If we end up having to remove libscalar-list-utils-perl from Debian, I guess we could also consider patching the bundled core version to newer CPAN releases in this case. -- 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
