Update: Excellent points made in responses. A rewrite is in the works. Keep them coming.

Perhaps this is a tutorial, or perhaps something that just belongs long term in Meditations, but my intent with this node is to document the arguments related to modifying the system's Perl installation, so that I don't have to lay out the argument every time it comes up in SoPW. There are some pro, and some con, but it seems to be, in my experience, that "Can't touch this", if given the choice, is the correct path to take.

Some of the previous comments I have made on this topic can be found here: SuperSearch Preload

So, without further ado, here are some arguments in favor of installing your own Perl (in no particular order):

• Modifying the system Perl can break the OS.
• Updating the OS can change the underlying Perl, breaking your application.
• You don't necessarily have control over the system's Perl.
• Updating the system's perl for application's needs can go against another application's needs.
• The system's Perl may not be complete.
• By packaging Perl with your application stack, you control the installed modules and toolchain.
• It is easier to target a single Perl version than anything you might find on the OS.
• Policy may disallow installing a "necessary" module on the system's Perl.
• Your installed / updated CPAN modules may be overwritten (and downgraded) by OS updates. - Corion
• You are (safely) limited to the module versions provided in packages by your vendor - Corion

There are also some cons to installing your own Perl:

• Your application distribution now requires or includes a separate Perl distribution.
• Your packaging requirements are now more complex.

In summary, unless you are writing an OS-level tool specifically for this platform, install a Perl version specifically for your own application's runtime stack.

Anything else? (ed: updates tagged with author)