http://qs321.pair.com?node_id=1034412


in reply to Why upgrade perl?

In most cases, rolling your own Perl does not require an inordinate amount of work. I refer to you to Perlbrew and cpanminus, both of which can be potentially life-changing.

The benefits of running your own Perl go beyond the new language features (which are significant between 5.10 and 5.18; see perldelta for more information). By running your own Perl, you gain complete control over what you upgrade, and when you upgrade. OS Perl releases are often for the benefit of the OS itself: to support scripts used by the particular Linux/UNIX distribution you run, so those releases tend to lag pretty far behind. In this case, five and a half years! The releases are often patched as well, either to backport bug fixes, or for other reasons. Hence, you are not running vanilla Perl.

For these reasons, you will often have trouble installing CPAN modules, and are often faced with the dilemma of whether to use the (older) RPM provided by your Linux distribution, if anyone bothered to package it at all, or abandoning it entirely if it won't install via CPAN due to incompatible dependencies or Perl version.

Running your own Perl will fix these issues, but note that any Perl modules that depend on C/C++ libraries may still cause problems if the RedHat versions lag too far behind. Staying with the OS Perl and OS-packaged mods usually avoids this issue by keeping all the versions in sync even if they're old, or not providing packages for newer modules.

Nothing's perfect, but once you get past the fear of the unknown and acclimate to the perlbrew process, many headaches go away.

That being said, upgrading the programming language (or its modules) that underlies a large programming project is not something to be done on a whim, as interfaces can change, subtle changes can cause bugs (such as the hash order randomization change), and other unexpected problems can occur. That is not to say that upgrading isn't worth it, but you would be well-advised to have a fallback plan, and an excellent suite of unit tests and manual test plan to quickly find any regressions.

Replies are listed 'Best First'.
Re^2: Why upgrade perl?
by dsheroh (Monsignor) on May 21, 2013 at 07:38 UTC
    For these reasons, you will often have trouble installing CPAN modules
    You're overstating the case. Granted, I'm a sample size of one, but, although my primary job description is "Perl programmer", I'm also the local devop[1], so I maintain several boxen running a mix of distros[2], some of which are rather ancient[3]. With the exception of Perl 5.8.x vs. 5.10, I have never encountered an issue with a CPAN module failing to install due to the system perl being too old. OP said he's currently on 5.10.1, so my experience suggests that this should not be an issue for him.

    [1] ...and used to be a full-time sysadmin, once upon a time.

    [2] The ones I install tend to run Debian and legacy systems are mostly Red Hat, but just about anything can pop up on occasion - SUSE, Mandriva, you name it.

    [3] The current oldest is a Fedora Core 5 server, which we finally managed to start moving things off of just last week.

      I am frankly quite intrigued why you say, “overstating the case,” because I certainly have encountered incompatibility issues on a great many upgrades.   And, given that RedHat’s most-essential software tools run on Perl, that does become a serious concern.   I am not challenging your POV, but it does surprise me to hear this.

        "And, given that RedHat’s most-essential software tools run on Perl, that does become a serious concern."

        Leaving the system Perl to the system is wise. Let the vendor do what they want, it's trivial to install your own Perl elsewhere.

        I feel that it's an overstatement to say that a too-old version of perl will "often" cause problems when installing CPAN modules, given my own experience that such problems are extremely rare, with the one exception of pre-5.10 perl vs. post-5.10 modules. It's interesting to see that your experience has been the opposite and that makes me wonder which is actually the more common set of experiences.