For me, this is the primary argument. The vendor's installation is the vendor's. They will not consult you to see if your application will run under a future (or past) version that they want to move to, nor will they rush an upgrade just because your application 'needs' some feature. You are able to test, package, and deploy your application based on your requirements, instead of the current implementation selected by your OS vendor.*
* Yes, this is a broad brush, and there are some instances where using the OS vendor's version of perl is the RightThing, but that is a tradeoff and business / marketing decision, IMO. Just my $0.02.
| [reply] |
I think it's valid argument only if your applications are really huge or they're bloatware without testsuite, full of legacy code with 100+ CPAN dependencies and full of technical debt. And you're totally unsure why it would/wouldn't work on certain version of Perl.
Otherwise it will be pretty easy to test it with several versions of Perl, on dev machine, to make sure the code matches Perl specification, and that you are not using some crazy CPAN modules. Any incompatibility will be a good reason to investigate the reason to make sure your code actually does not contain bugs. Easier deploy to RHEL servers is a bonus
| [reply] |
Until your OS patch changes the OS's version of perl (or a library) under the hood, breaking the assumptions made by your application. This happens in large enough organizations where 'the canonical OS platform is X.Y.Z, and all machines must be upgraded to X.Y.Z by this and such date' (yes, it does happen :-/ ). Using your own perl gives one fewer moving part not under your control.
If you are releasing on CPAN, then yes - test far and wide. There are times for both approaches.
| [reply] |
