Normally I would advocate to work with the operating system, not against it. (Because you get security updates for free without risking the bleeding edge of CPAN.) But with an ancient version such as 5.8.8? Yeah - perlbrew all the way.

It depends on how you view the OS. Here, I view it as a platform to place my application stack over. IT has responsibility for the OS, I have responsibility for the application. Since the goals and needs of IT at the OS level and my team at the application level are similar, but never identical, I have found that including the runtime environment within my application installation provides a much more stable and reliable application for my users. If the OS de jour changes (as it may), it also gives us (assuming proper isolation of the OS touch points) the ability to migrate while minimizing porting effort (a lesson learned the hard way).

Add into that vendors for part of my application environment that require a specific version of Perl (binary library distribution), and I actually have multiple versions of perl in my application stack. One for each vendor's required version, and one for my overarching application. The parts communicate along well-defined lines of demarcation, allowing for a smoother update process for each component. An additional benefit along for the ride is also being able to move part of the environment to another machine and basically being able to change the location of the resource.

It took me many years and may head/heartaches to settle on this configuration, but it seems to work quite well.

--MidLifeXis