If you're doing anything serious using the OS' perl is probably not what you want to do. If you're using the OS' perl then you're at the mercy of the sysadmin and/or whatever update schedule the upstream OS pick WRT when perl upgrades. Your best bet is to compile your own perl (perhaps using perlbrew) and explicitly use that instead. You'll have control of when you upgrade, what's installed from CPAN into that install (although you may want to be using local::lib as well).
It's more effort, but you'll appreciate the headache(s) you save yourself because you don't have to track down and fix things after your sysadmin (or RHEL) decides to force you to jump perl versions because a third order dependency makes /usr/bin/perl to jump versions and now all of your CPAN modules disappear.
(Caveat: if you're in a containerized environment and know you can lock down versions and what's installed specifically within your container and you're isolated from changes to the (base) underlying OS then this isn't as relevant a suggestion.)
Edit: While I'm not completely enamored with it as the mechanism your using anaconda I'd say is another acceptable solution akin to using perlbrew; the main thing is not tying yourself to the OS' perl. You want your application to run against a perl you completely control.
The cake is a lie.
The cake is a lie.
The cake is a lie.
In reply to Re^2: Weird perl issue, installed packages not being recognized
by Fletch
in thread Weird perl issue, installed packages not being recognized
by kvn95ss
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |