On Mon, Nov 14, 2016 at 3:11 PM, Todd Rinaldo <to...@cpanel.net> 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-removin > g-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. > > We have come up with several ways to mitigate and ultimately fix the > problem: > > Short Term > > Perl 5.26 will support an environment variable "PERL_USE_UNSAFE_INC=1". If > you set this, any perl script invoked will include . at the end of @INC. > Tentatively, support for this environment variable will be immediately > deprecated since long term, the CPAN modules need to simply take this into > account. > > My current thinking is that if we inject this environment variable into > the CPAN clients (cpanm, cpan, cpanplus, etc.), then they will build and > install modules as they normally did. Packagers (RPM, deb, etc.) will also > need to amend their build systems by also setting this environment > variable. It is also possible that a fix will be require to CPAN smoke > testers. > I think this breaking change is sadly unavoidable. I'm not so sure about the immediate deprecation though. In the toolchain we can't really deprecate things except by dropping support for a perl version (which is a rare event). Simply put, the benefit of dropping support for this workaround is relatively small (we can remove a small amount of code that isn't standing in the way of progress), and the cost is high (modules that can no longer be installed easily). One could argue it serves as an additional pressure on authors to fix things, but I'm not fond of that sort of technical solutions to social problems. As ugly as the workaround may feel to me, simply getting rid of it seems worse. > Long Term > > We need to fix the CPAN modules themselves. The vast majority of modules > can be fixed by putting use lib "."; at the top of Makefile.PL or Build.PL. > Others will need to fix additional scripts in their tree to also take this > into account. In some cases use blib; might be more appropriate, for > instance, in unit tests which invoke child scripts. > > My original proposal included a patch to ExtUtils::MakeMaker, > Module::Build, and Module::Build::Tiny. At this point I think that this > might be the wrong place to fix the problem. > There are essentially 2 kinds of breakages: * configure time (mainly Module::Install, and a few others but not many). * testing time (mainly libs directly under t/ instead of using an explicit t/lib). Injecting the environmental variable in the CPAN clients fixes both issues, but only for people who are using CPAN clients. Which is thankfully the vast majority of people but there are people and situations that require manual installs. Injecting in the install tool can only fix testing issues, but can actually fix them for all users, including manual ones. To me this is less valuable that the former workaround, but that doesn't mean it doesn't have value (though I find it rather distasteful). Manually installing non-updated Module::Install dists will be the painful quadrant no matter what. Module::Install is a gift that keeps on giving. Leon
