Perlbrew to the rescue

Chromatic recently posted about the support lifetime of Perl, and it's extension through enterprise distributions. While I don't particularly buy his arguments against enterprise need for back-patching and supporting older versions of Perl (and I suspect neither does he completely. He always strikes be as somewhat of a provocateur, a noble profession), I do agree that App::perlbrew is part of the solution.

While we seem to be in agreement that perlbrew is the solution, he seems to think (it's ambiguous in the post) that perlbrew can't be included in existing enterprise releases, such as RHEL 5 (which I'm most familiar with, and will restrict my examples to). I don't see any major reason that it can't be made available to existing enterprise distributions (in a supported manner, even). RHEL has a long history of providing feature enhancements and new packages/programs in their point releases (as opposed to the strictly bug and security fixes between point releases), so including perlbrew would be easily accomplished. Even if RHEL doesn't want to include it for whatever reason, getting it included in CentOS through their extras would be trivial (well, as trivial as doing anything with the CentOS developers is these days), and provide a real enhancement.

Of course, the Perl versions installed from perlbrew themselves would not necessarily be supported, but that's an easy point of demarcation to define. Different support policies could (and should) be defined for applications developed and/or deployed on a platform, as opposed to the platform itself. This allows for easy updating of subsystems that aren't related to the deployed application, but are required for security reasons.

I remember the most recent time I was migrating (and updating) RT. I spent quite a while swimming through dependency hell, making RPMs of all the required CPAN modules that weren't already available through RPMForge, EPEL and the like. During the final stages of that, visions of making my own RT bundle that auto installed Perl through perlbrew, along with the latest relevant CPAN modules were definitely dancing through my head. I think the world is a more barren place for my lack of motivation after the migration project was complete.

Now, for anyone who really just doesn't get why enterprise distributions need to keep the old version of Perl around, consider the following; enterprise distributions need the ability to ensure that during any update, nothing can or will go wrong (at least as much as they can). This often means limiting an installed program to the original shipped version, and back-porting non-conflicting features. When you have to upgrade hundreds of servers, this is essential. This is the continual struggle between system administrators and developers. Both groups are striving for stability, maintainability, and security, but these concepts mean slightly different things to each group. The beauty of perlbrew is it allows each group to have their own sandbox that they can correctly apply their goals to.

Please note than while I'm not sure the support requirements of perlbrew itself, if they aren't as minimal as possible to run on as old a version of Perl as possible, than I see that as a serious design flaw. I don't believe this to apply to CPAN modules in general though.