develooper Front page | | Postings from April 2017

Re: Updated CPAN River available

Thread Previous | Thread Next
James E Keenan
April 17, 2017 03:19
Re: Updated CPAN River available
Message ID:
On 04/16/2017 09:46 PM, Ricardo Signes wrote:
> * James E Keenan <> [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
> 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

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About