Perl 5.8.8 was released on 31 January 2006. There have been six stable releases of Perl 5 since then, including Perl 5.8.9 on December 14 2008. Yet if you install an Enterprise Linux Distribution such as RHEL 5.5 or CentOS 5.5, the base system Perl will be an ancient version of Perl 5.
Warning, some tongue-in-cheek rhetoric ahead.
I realize that Red Hat makes its money from businesses who believe computers are scary black boxes that fall over when you think "Maybe I'll say 'Boo!' at them!" and so it's very much worth Red Hat's time to charge lots of support dollars to release untouched versions of software for businesses which never upgrade their software not to upgrade to, but I'll eat my hat if that leads to any of those support dollars making Perl 5.8.8 more robust, more secure, less buggy, faster, or better to use.
(The previous paragraph is not entirely serious. I'm not wearing a hat, for example.)
Of course, Red Hat (like all good hearted operating systems) uses Perl 5 as part of the core system because it's so useful to get things done. Making any change at all to the core Perl 5 would mean that Red Hat or Fedora volunteers would have to figure out some way of verifying that changes are okay, and if not, they'd have to file bug reports and get them resolved somehow. That's a lot of work!
Red Hat (and other distributions) can distribute the versions of software they want. If they're happy with an ancient Perl 5, let them write their software. They make their choices and they pay the penalties.
Spoiler alert: the remainder is completely serious.
I can't, however, in good conscience recommend that anyone writing a new Perl 5 project in late 2010 use the system Perl 5 for anything other than installing App::perlbrew and then immediately installing a modern release of Perl 5, such as the shiny new Perl 5.12.2. It won't hurt, and you'll have access to wonderful features and improvements and—most important—you'll get support from the Perl 5 community which makes great things for you to use.
It's great that Perl has been a useful Unix tool for such a long time, and it's very good that distributions use it for their core utilities. Yet we shouldn't let their inability to manage software in conjunction with upstream get in the way of users trying to do useful things.
The ancient core Perl 5s installed by default by so-called Enterprise distributions are dead to me. They're the Internet Explorer 5 of the programming world: sufficient only to upgrade to something better. (Wouldn't it be a finer world if they could install their creaky old core Perl 5 in a core do-not-use-this directory of its own and give users something better by default?)
It's not just old features either. CentOS Perl had the rebless bug (perl bug #34925) that reduced DBI to a quivering wreck after a few hours of use. Since this was part of core Perl, the only way around it was to install a new clean version. This bug persisted in CentOS system Perl for more than two years after the fix had been applied to the Perl sources. The system Perl may have unfixed bugs which seriously affect your app, but not the administration tasks their Perl install was designed to support. And there is nothing you can do to resolve them.
That leaves us with only workarounds, which is explicitly not supporting vendor Perls. I waffle about removing support for anything older than Perl 5.10.1 from my CPAN distributions.
What a luxury situation! (Ok, I am wearing a funny hat.)
We Solaris users are stuck with 5.8.4 (Solaris 10) in a world with a lot (most) of Solaris 8 installations (Perl 5.6.*)...
I had to use a Solaris 2.3 box a couple of years ago. I didn't have the heart to check the versions of any software I cared about.
Is there a normal, community-driven process for getting updates into RHEL, i.e. can you package a RPM/SRPM and contribute it to the Fedora project?
Maybe EPEL is what you are looking for:
http://fedoraproject.org/wiki/EPEL
@grokify, Fedora 14 currently has Perl 5.12.1 which is pretty good (since 5.12.2 was just released a few days ago) so getting a modern version of Perl into the community version is already happening. It's getting things into the "enterprise" version that doesn't seem to move.
@mpeters, thanks for the post on Fedora. RHEL 6 beta (ftp://ftp.redhat.com/pub/redhat/rhel/beta/6/i386/os/Packages/) has 5.10.1 which is the latest version of 5.10 and just barely over a year old. Given that 5.12.2 is only 5 days old, that version is probably too recent to include in RHEL. What does everyone think is a reasonable version of Perl for RHEL 6?
What is a better way of deploying perl software to a large number of machines?
The organization I work for writes a lot of perl code that we deploy to over 50 CentOS 5 machines. All our in-house and third-party software is packaged into RPMs and distributed through our yum server. Perl module dependencies are fulfilled through the CentOS repositories, EPEL or, if needed, packaged ourselves. Everything runs using the system perl.
This has forced us to accept that we can't use the bleeding edge for everything. But I don't think that has hurt us significantly. However, having all software be deployed to our production systems through RPM exclusively has help us immensely by making deployments almost foolproof.
I would really like to use the latest perl and all the latest modules but I haven't been able to justify the cost of making our deployments more difficult. I would really like to know what other people do in this kind of situation.