Skip Menu |

This queue is for tickets about the mod_perl CPAN distribution.

Report information
The Basics
Id: 131952
Status: open
Priority: 0/
Queue: mod_perl

People
Owner: Nobody in particular
Requestors: tom [...] eborcom.com
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: 2.0.11
Fixed in: (no value)



Subject: Installation gets stuck in an infinite loop
With a freshly installed perl (v5.31.9-15-g34667d08d3) I ran `cpan ModPerl::Global` from the command line. The installation process soon got stuck in an infinite loop, repeatedly outputting the same message: Please provide the location of the Apache directory: [ error] Can't find dir '' It might be worth replacing the `until ($ok)` on line 262 of Makefile.PL with something that only tries a few times, or perhaps a better solution exists. I do not have apxs installed, but I would expect the installation process to handle this more gracefully. Please let me know if you need more information.
On Mon Feb 24 08:02:19 2020, TOMHUKINS wrote: Show quoted text
> With a freshly installed perl (v5.31.9-15-g34667d08d3) I ran `cpan > ModPerl::Global` from the command line. > > The installation process soon got stuck in an infinite loop, > repeatedly outputting the same message: > Please provide the location of the Apache directory: > [ error] Can't find dir '' > > It might be worth replacing the `until ($ok)` on line 262 of > Makefile.PL with something that only tries a few times, or perhaps a > better solution exists. I do not have apxs installed, but I would > expect the installation process to handle this more gracefully. > > Please let me know if you need more information.
I, too, have been *repeatedly* burned by this flaw in the mod_perl distribution. From late 2017 to this year I operated a program which tested how well a monthly development release of perl could handle installation of a list of 3000 distributions from CPAN in dependency order -- the so-called "CPAN River 3000." I learned the hard way that many CPAN distributions have been broken for years and that others, shall we say, behave badly in automated testing environments. For example, some distributions botch their attempts to establish network connections while running 'make test' and lead to a time out -- which slows down the entire CPAN-River-3000 program by 30 minutes per timed-out distribution. But mod_perl is far worse. It goes into the infinite loop described by the first poster to this ticket. If I'm running my program in a VM, the mod_perl error messages described by the first poster have the potential to fill the VM's memory. I've generally been able to work around this in two ways: * I've carefully curated the list of modules in the CPAN River 3000 to exclude mod_perl and any of its reverse dependencies. * I've used 'cpanm' as my installer rather than 'cpan'. I chose 'cpanm' simply because I had gotten very accustomed to using it over the past decade. But I recently became aware that it has a hidden advantage over 'cpan' in that it does *not* attempt to install distributions which are listed in a distro's META.json files as 'runtime:recommends' or 'testing:recommends'. Recent versions of 'cpan' (see 'perldoc CPAN::FirstTime') have an 'experimental' feature called 'recommends_policy' which *by default* is turned *on*, not off. So if you install a new perl and, along with it, the CPAN.pm and 'cpan' command-line program that come with it, you are -- almost certainly without being aware of it -- going to get 'runtime:recommends' distros installed. And when (as in the case of, say, SOAP::Lite) one of those 'runtime:recommends' is 'Apache', then your invocation of 'cpan' is doomed to an infinite loop. So, please, fix this problem so that mod_perl behaves nicely in automated testing and installation environments. Thank you very much. Jim Keenan