Re: RFC: (Do Not) Modify the System Perl

[sundialsvc4]

Pragmatically speaking, you probably can at-least tolerate “the system Perl,” provided (a) that it is of a sufficiently recent version, and (b) that you can cleanly ensure that “your app” will always encounter “your version” of those libraries which actually matter to “your app,” superseding any system alternatives.

If you are stuck on a shared-host service whose Perl is unacceptably ancient, then, yeah, you have to install your own Perl.   (But, some hosts do not allow you to install binary executables.   Catch-22.™)

Otherwise, you may be perfectly all right setting up an application-specific library directory, ensuring that it is first on PERL5LIB (or use lib), ensuring also that cpan[m] points to it, and then installing(!) the app-important libraries (via cpan[m](!) ...) into that location.   The module-installation process will see the entire @LIB list ... including “the System Perl” on this particular system ... and will Do The Right Thing.™   But this only works because cpan[m] can see the System Perl environment as it lurks just-behind your app-specific directory in the module search order, and because of the total set of work that each package’s installation scripts do.

All of this, of course, is enormously influenced by ... XS.   (Such that, really, this one concern rules them all.)   Any [Perl] application is likely to make many references to .so or .DLL libraries that are present on the system, and there is unfortunately a very good chance that you cannot supersede nor replace too-old versions of those!   :-X

And all of this presupposes that your app has a thoroughly-complete Test::Most suite, and that you run it to verify that the application does run correctly in its target environment at the conclusion of your installation sequence.