Re: Bug#721364: perl: Missing Pre-Depends/Breaks/Conflicts wrt. libscalar-list-utils-perl and the Perl 5.18 transition
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 ntyni@debian.org
Reply to: