Re: Updated CPAN River available

On 04/16/2017 09:46 PM, Ricardo Signes wrote:
> * James E Keenan <[email protected]> [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