Beefy Boxes and Bandwidth Generously Provided by pair Networks
P is for Practical
 
PerlMonks  

Re: Why upgrade perl?

by rjt (Deacon)
on May 20, 2013 at 21:46 UTC ( #1034412=note: print w/ replies, xml ) Need Help??


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.


Comment on Re: Why upgrade perl?
Re^2: Why upgrade perl?
by dsheroh (Parson) 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.

        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.

        "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.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://1034412]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others drinking their drinks and smoking their pipes about the Monastery: (7)
As of 2014-10-02 04:10 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    What is your favourite meta-syntactic variable name?














    Results (48 votes), past polls