Bug#732191: perl-base: separately packaged XS modules can break system upgrades

[Dominic Hargreaves]

On Sun, Dec 15, 2013 at 04:59:02PM +0200, Niko Tyni wrote:
> (I've cloned #721364 to track the more general problem as a separate
> bug, #732191.)
> 
> On Tue, Dec 10, 2013 at 09:00:19PM +0100, gregor herrmann wrote:
> > On Sat, 31 Aug 2013 18:30:25 +0300, Niko Tyni wrote:
> 
> > > I think we need to remove libscalar-list-utils-perl altogether.
> > > I'll file a separate bug on that soon.
> > 
> > Next one: CPAN-Meta 2.133380 now wants List::Util: 1.33 (which is in
> > core in 5.19.5).
> 
> I see that's for the new function List::Util::all(). It's unfortunate
> that we've ended up with a still evolving interface in perl-base.
> 
> I see short and long term solutions.
> 
> A. carry on without List::Util 1.33, patch CPAN-Meta to not use the new
>    functionality before it gets in the Perl core
>   * this burden may grow in the future as more modules need patching
> 
> B. bundle List::Util 1.33 in perl-base
>   * what's the right thing to do with Module::Corelist ?
> 
> C. make the separate version install its files somewhere outside
>    the default @INC and make CPAN-Meta look there
>   * tempting but far from elegant
> 
> (D. add fallback pure Perl versions to all the XS functions as a Debian patch
>    * keeping these up to date would be a permanent burden)
> 
> I had a brief discussion with Brendan O'Dea about this, and he had a
> couple of ideas:
> 
> > 1. Include a new /usr/{share,lib}/perl-base/<ver> directory pair early in @INC
> >    (before vendor), and install the perl-base modules there.  This would enforce
> >    the policy of disallowing the packaging of modules in base by effectively
> >    ignoring them.
> > 
> > 2. A slight amendment to the above is also possible, but would require non-
> >    trivial changes to potentially lots of maintainer scripts.  The idea being
> >    that the /usr/bin/perl binary would have the perl-base directories *after*
> >    vendor in @INC, but there would additionally be a /usr/bin/perl-base in the
> >    perl-base package which *only* included the perl-base directories in @INC.
> > 
> > This second option might well be a better option in the long term, as it would
> > catch packages which were using perl incorrectly in maintainer script
> > (e.g. depending on modules which may not be available) but would unfortunately
> > mean changes to potentially lots of maintainer scripts.  A lintian check could
> > probably look for maintainer scripts using perl in #! and explicit uses of
> > "perl -e".
>  
> I think the /usr/bin/perl-base idea feels "right", but it's a lot of work
> and I'm not sure how feasible it is. I suppose postinst scripts can be
> excluded. How about dpkg triggered actions?
> 
> At the very least, it would mean a wait of one release cycle before
> the maintainer scripts could start relying on /usr/bin/perl-base in
> all situations.
> 
> I'd welcome opinions and thoughts about this so we can decide if
> we want to do it for jessie.
> 
> For the short term, I'd lean towards patching CPAN-Meta, perhaps to
> use List::MoreUtils::all() from liblist-moreutils-perl instead. We can
> revisit including the newer Scalar-List-Utils in perl-base once there
> are more modules needing them.

Agreed - I don't think we need a heavyweight solution whilst the problem
only manifests in one place. I've uploaded a patched version of CPAN-Meta
now.

Cheers,
Dominic.