> 40 minutes later its trying to autoselect the same broken mirror
Sounds like you're in a network with particularly misbehaved firewalls. The initial phase of the auto-setup is very fast, since it only checks file paths. The network part might be slow if some part of your network infrastructure messes with connections and cuts them without properly resetting, resulting in super long timeouts.
Not sure what you expect in such a situation.
> a broken install.
No you don't, unless it's an extremely old or shitty library you chose to dep on, since things build, run their tests, and only install when those pass. The 6 pages of output help you identify which tests failed and maybe why. Also, often test failures are simply because you have a system the author didn't write for, which hurts just as much with the other packaging systems.
Broken install = it didn't install. I had no idea why. I did get there after some hours of struggle . Part of the problem is the libraries on our system are everywhere.
Sorry I sounded cranky, truthfully I'm probbly just unfamiliar. I'm a developer not an admin, just want to install packages. We developers love the package systems and cpan pioneered a lot of it.
A great package manager goes a long was to helping a languages success.
I'm comparing to Gems, composer, npm, rpm which for what I've done with them work pretty flawlessly and easily.
cpanminus (cpanm) is an attempt to make a zero-configuration client
that automatically does the right thing for most users. It's also
designed to run well on systems with limited resources (e.g. a VPS).
It doesn't come with Perl, but it's easy to install.
It integrates easily with local::lib.
> I had no idea why. ... Sorry I sounded cranky, truthfully I'm probbly just unfamiliar.
Yes. CPAN does a lot to help the user and gives a lot of information, but all that information truly does contain 99% of what you need.
It progresses in phases (prep, make, test, install) just like most other make-based software (99% of the stuff installed on your linux boxes) and after each phase it will say "<phase> OK"/"<phase> NOT OK", so you only have to read for that, then scan upwards to see what errors you got from gcc or whatever. In other words, and i'm not trying to be mean, but: You only have to read what is on your screen.
As for "Gems, composer, npm, rpm", i know that the three non-npm ones don't run tests on install (npm probably doesn't either), so you might be conflating "flawless and easily" with "system incompatibilities are found at runtime, instead of install time". I.e. it's highly likely that what you like of them isn't that they've progressed beyond CPAN.pm, but that they've yet to catch up to it.
Sounds like you're in a network with particularly misbehaved firewalls. The initial phase of the auto-setup is very fast, since it only checks file paths. The network part might be slow if some part of your network infrastructure messes with connections and cuts them without properly resetting, resulting in super long timeouts.
Not sure what you expect in such a situation.
> a broken install.
No you don't, unless it's an extremely old or shitty library you chose to dep on, since things build, run their tests, and only install when those pass. The 6 pages of output help you identify which tests failed and maybe why. Also, often test failures are simply because you have a system the author didn't write for, which hurts just as much with the other packaging systems.