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