(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.
--
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
