On 11/14/2016 09:11 AM, Todd Rinaldo wrote:
> Howdy,
>
> I've done a write up of a recent change to blead perl. In the future
it will no longer be possible to count on . being in @INC. This will
break many of the existing CPAN installs.
>
> It was suggested I send the RFC here:
>
>
http://blogs.perl.org/users/todd_rinaldo/2016/11/how-removing-from-inc-is-about-to-break-cpan.html
>
> In Perl 5.26, it will no longer be a safe assumption to assume . is
in @INC. This is a good move towards a more secure Perl, but will break
the installation of many CPAN modules. For those of you wondering why
this was done, see this post for more information.
>
> Many CPAN modules try to do things like: use inc::Module::Install;
This depends on . being in @INC. If you invoke Makefile.PL without it,
the script will not even run.
>
Here is a use case which I found very soon after building a perl at
blead with the new option and then installing App::cpanminus against
that perl.
#####
Summary of my perl5 (revision 5 version 25 subversion 7) configuration:
Commit id: dd4f16e4ff71ea6d0422d277f00fe430e1d93938
[snip]
config_args='-des -Dusedevel -Uversiononly
-Dprefix=/home/jkeenan/testing/nodot -Dman1dir=none -Dman3dir=none
-Ddefault_inc_excludes_dot'
[snip]
@INC:
lib
/home/jkeenan/testing/nodot/lib/perl5/site_perl/5.25.7/x86_64-linux
/home/jkeenan/testing/nodot/lib/perl5/site_perl/5.25.7
/home/jkeenan/testing/nodot/lib/perl5/5.25.7/x86_64-linux
/home/jkeenan/testing/nodot/lib/perl5/5.25.7
#####
I used ./bin/cpanm to install one of my CPAN distros that has a
second-level dependency on another one of those distros,
Perl-StringIdentifier.
#####
Building and testing String-PerlIdentifier-0.05 ... FAIL
! Installing String::PerlIdentifier failed. See
/home/jkeenan/.cpanm/work/1479138905.14485/build.log for details. Retry
with --force to force install it.
#####
Let's inspect that build log.
#####
PERL_DL_NONLAZY=1 "/home/jkeenan/testing/nodot/bin/perl"
"-MExtUtils::Command::MM" "-MTest::Harness" "-e" "undef
*Test::Harness::Switches; test_harness(0, 'blib/lib', 'blib/arch')" t/*.t
Can't locate t/eligible_chars in @INC (@INC contains: t/
/home/jkeenan/.cpanm/work/1479138905.14485/String-PerlIdentifier-0.05/blib/lib
/home/jkeenan/.cpanm/work/1479138905.14485/String-PerlIdentifier-0.05/blib/arch
/home/jkeenan/testing/nodot/lib/perl5/site_perl/5.25.7/x86_64-linux
/home/jkeenan/testing/nodot/lib/perl5/site_perl/5.25.7
/home/jkeenan/testing/nodot/lib/perl5/5.25.7/x86_64-linux
/home/jkeenan/testing/nodot/lib/perl5/5.25.7) at t/Auxiliary.pm line 14.
Compilation failed in require at t/01_basic.t line 8.
BEGIN failed--compilation aborted at t/01_basic.t line 8.
# Looks like your test exited with 2 just after 1.
t/01_basic.t ......
Dubious, test returned 2 (wstat 512, 0x200)
Failed 40/41 subtests
#####
Here's what that distro has in/under its 't/' directory.
#####
$ ls t |cat
01_basic.t
02_specified.t
03_min.t
04_max.t
05_default.t
06_no_scores.t
Auxiliary.pm
eligible_chars
#####
#####
$ head t/01_basic.t
# t/01_basic.t - four basic tests
use Test::More tests => 41;
use strict;
use warnings;
BEGIN { use_ok( 'String::PerlIdentifier' ); }
use lib ("t/");
use Auxiliary qw{ _first_and_subsequent };
four_basic_tests() for (1..10);
#####
$ head -15 t/Auxiliary.pm
package Auxiliary;
use strict;
use warnings;
our ($VERSION, @ISA, @EXPORT_OK);
$VERSION = '0.05';
require Exporter;
@ISA = qw(Exporter);
@EXPORT_OK = qw(
_first_and_subsequent
);
*ok = *Test::More::ok;
use lib ('.');
our (%eligibles, %chars);
require "t/eligible_chars";
#####
The test file attempts to load Auxiliary.pm, which is located in the
same directory as the test file. Auxiliary.pm in turn 'require's a
plain-text file, 'eligible_chars', which is also located in t/. That
'require' fails.
In this case, adding '.' to the distribution's Makefile.PL made no
difference. I had to add "use lib ('.');" to Auxiliary.pm to enable it
to locate 'eligible_chars', after which 'make test' PASSed.
Based on this example and several other failures, my hunch is that many
of the failures which we'll see on CPAN are failures of *tests* rather
than failures of the modules themselves.
Thank you very much.
Jim Keenan
