RHEL and perl
At Jobindex we use Red Hat Enterprise Linux. The OS is very stable and we feel that Red Hat is doing a lot of good stuff for Linux and OSS in general.
When it comes to perl the current version RHEL ships with version 5.8.8 which causes a bit frustration however. Some CPAN modules won't install and it seems like the people who writes modules for CPAN don't really care about our (good) old perl verison.
At YAPC::EU several of the speakers recommended installing perl ourselves instead relying on the OS version.
We have now decided to follow this recommendation. At the same time we will also start using git to manage perl and the installed modules to keep the versions in testing and production in sync. This way we wil also avoid messing with RPM packages.
So now I am looking forward to getting my hands on perl 5.12.2 :)
I blog about Perl.
Even if you have a recent Perl installed I highly recommend not using the system Perl and instead install your own with Perlbrew. Perlbrew makes this take trivial and you gain the benefits of using a Perl that is totally under your control for the purposes of development and not subject to arbitrary changes and updates that may be necessitated by Red Hat security patches.
Try to think of the system Perl as a runtime used by the OS for vital functions and just ignore it for the purposes of writing and running your applications. You will be much happier in the end and will have a Perl that you will be able to upgrade on a schedule of your own choosing.
I've personally foundPerlbrew, local::lib and cpanminus to have solve the majority of my dependency management problems.
Hi
When you say that "people who writes modules for CPAN don't really care about our (good) old perl verison" that is not entirely correct. In fact, some developers backport their modules so that they can be used with older Perl versions. But, in the other hand, you need to see this as an incentive to progression. If all modules are 5.8.8 compatible, what do we need new features for? So, making good modules working on recent Perl version can, or might, help convincing users to upgrade their Perl versions. If not system wide, at least in the same way you did :)
Cheers
ambs
Thank you for your comments.
@john: I tried perlbrew and it is pretty cool. We were going to use it but then I found this article on stackoverflow by brian d. foy which recommended against perlbrew and mod_perl.
http://stackoverflow.com/questions/3794922/how-do-i-use-perlbrew-to-manage-perl-installations-aimed-at-web-applications
So we chose not to use perlbrew since we are indeed using mod_perl.
@Alberto: I totally respect the module maintainers choice to use the features from the more modern versions of perl. As soon as I get by hands on perl 5.12 it will only take minutes before I start using the new features myself :)
You left off the most important part of the quote "Some CPAN authors...". It's true that some authors are writing stuff that intentionally uses the newer versions of Perl.
At the same time we will also start using git to manage perl and the installed modules to keep the versions in testing and production in sync. This way we wil also avoid messing with RPM packages.
I think your desire to use your own Perl binary has merit and will benefit you in the long term. But for what it is worth, I spent dozens of hours at a previous employer (who also used RHEL) migrating them away from this setup (except they were using svn instead of git).
Dependencies were more difficult to track using version control as opposed to rpms where you can explicitly specify dependencies. The subversion repo became quite large, and increased the update time for developers (yes, git is faster, but you will still have this problem eventually). Module handling for developers becomes more problematic - they may have one version of a module in their perl lib, and another in the git repository. You can't easily upgrade modules and test them out. Incremental issues become difficult to sort out when you push out several different modules in one repo as opposed to an rpm based approach - you lose the benefit of atomicity that rpms give you.
Creating rpms for your own Perl binary is not as difficult as it sounds. Creating an rpm for your own Perl binary is difficult however - that took me some development cycles to get right, but in the end it was worth it.
I would suggest really considering using RPM - there is a certain amount of pain involved, but once you get over that, you avoid all of the nasty problems that you will encounter with the version control based deployment approach. Having seen both approaches in action on a very large code base, I recommend the RPM based approach.
Sadly, perl 5.10 is slated for rhel6 rather than perl 5.12
My workplace is a large rhel and perl user, so we have placed a formal request for 5.12 in rhel6.
Can i recommend that other rhel users log in to the redhat support site and request perl 5.12 in rhel6.
At least the new redhat will have a new perl version, rather than a 2+ year old one.