in reply to RFC: (Do Not) Modify the System Perl

In practice, this is very much like “installing Perl packages as a non-root user,” i.e. the shared-hosting situation.   I used to try to engineer the value of PERL5LIB to contain a certain value, but most recently I’ll use a stub script that issues use lib statements, then instantiates an object representing the main routine and invokes it, doing all of these things within an eval{} error-trap block.

As stated earlier, I will explicitly install whatever is needed by a particular application, into a private library-directory, always using cpan so that all installation scripts and dependencies are correctly handled.   If the system-Perl environment is updated, you may need to re-install one or more packages.   Only once did I encounter a too-old .so-file issue, and for various arcane reasons I had to switch hosting-companies in order to solve it.   (Shared-hosting providers are becoming increasingly restrictive, for obvious reasons.)