On 04/16/2017 09:46 PM, Ricardo Signes wrote:
* James E Keenan <jkee...@pobox.com> [2017-04-12T22:15:22]
For me the most interesting aspect of this fifth round is that 29
distributions which appeared in order-of-battle-20170409.txt (the
previous round focusing on no-dot) no longer appear in
order-of-battle-20170412.txt. That is, their no-dot problems -- and,
perhaps more importantly, the no-dot problems of their prerequisites
-- have been resolved and the distros are now installable under
PERL_USE_UNSAFE_INC=0.
Sub::Exporter::ForMethods appeared on that list, but as far as I know, it
doesn't need a new release, unless it's to require a higher version of prereqs.
That won't actually be a problem, though: what's needed is for a fresh install
of v5.26.0 to find a newer version of the prereq. The downstream module
doesn't actually need to know about it or require it.
I must admit I haven't been following this closely, but it seems to me like the
most useful list is:
* which modules are, on their own, broken
* ...possibly with a count of how many downstream things they break
It has become clear that there is more than one way to do an analysis of
CPAN dependencies at the approach of perl-5.26.0.
You could say: Let's rely on the fact that the major CPAN installers
have been patched to export a true value for PERL_USE_UNSAFE_INC into
their environments when they configure, build and test a CPAN
distribution. In this case an error other than "no-dot" in a distro's
prerequisites will prevent one's perfectly sound distro from being
installed, but a "no-dot" error in one's prereqs will not prevent your
distro from being installed.
Or you could say: At some point those CPAN installers will no longer
"cheat"; they will not export a true value for PERL_USE_UNSAFE_INC into
their environments. "no-dot" errors in any distro will be mercilessly
exposed. A "no-dot" error in a distro at the top of a tree of
dependencies will prevent all those dependencies from being
automatically installed.
I've taken each of these approaches -- "lax" and "strict" -- at
different points over the past month. What I took in the "fifth round"
is the second approach. Module-Runtime is probably the ultimate cause
of Sub::Exporter::ForMethods' failure to inst all in the "strict" approach.
Or you could mix and match these two approaches. I believe that Ryan
Voots has, in effect, done this, by first testing a distro under
"strict" and then, if it fails, under "lax".
In this case, Mac::SystemDirectory is a huge culprit, breaking File::HomeDir
installs on macOS, which breaks a holy ton of downstream things. I don't think
it appeared on your list.
I'm testing mostly on Linux, a little on FreeBSD. So I won't be able to
pick up Mac- or Win32-specific problems.
Let me know if there's anything else I can provide.
Thank you very much.
Jim Keenan
