Installing Perl: A Chicken-and-Egg Problem
A couple days ago the SD card on a Raspberry Pi lost its beady little mind, and I ended up rebuilding the system from scratch. I generally build my own Perl (also from scratch) and then install the modules I need. So that I can have a log file to rummage through in the event of a problem, I start by configuring the CPAN client interactively, and then doing
$ cpan YAML 2>&1 | tee YAML.log $ cpan Bundle::CPAN 2>&1 | tee YAML.log
Normally I would now install the modules specific to my use. But when I tried this time I got
HTTP::Tiny failed with an internal error: IO::Socket::SSL 1.42 must be installed for https support Net::SSLeay 1.49 must be installed for https support
What happened here is that last fall the CPAN client was updated in response to a spoofing threat. The change consisted of adding a Boolean configuration item,
pushy_https, which causes the client to ignore its
urllist configuration and retrieve modules from
https://www.cpan.org/. Now, core Perl does not support
https:, I have to get it by installing (among other things)
Net::SSLeay. But Perl 5.34.1, being a maintenance release, comes with the same CPAN client as 5.34.0 -- that is, it does not have
pushy_https setting and associated machinery. But when I installed
Bundle::CPAN, I got the latest CPAN client, but not the
https: support it wants by default.
Fortunately, all was not lost. The default value of
http: is in fact supported. So I could simply set
0, install what I needed, and then set
1 and continue my merry way.
But I wondered what someone unfamiliar with recent Perl history would make of this. Would this person fight through to the solution, or simply give up on Perl in disgust?
Obviously if core Perl supported
https: this would not be an issue. But much as I would like to see that, I understand (or at least sympathize) with why it is not happening any time soon. And I can not advocate defaulting the CPAN client to unsafe behavior.
But is there no way to give the poor user any help? The unconfigured value of
undef, which the CPAN client interprets as true. Could that value at least cause a more helpful error message?
Truth in advertising: normally I install from a Mini-CPAN mirror, so in my case I just pointed the CPAN client to that mirror. But I thought the more typical case was to install from www.cpan.org, so after I got my Raspberry Pi going I did that with another Perl install, just to be sure I was reporting a general problem and not one I had completely caused myself.