Keith Lofstrom wrote on pdx.pm:

> I suspect that the book I really want will be titled something like
> "Administering Perl". This imaginary book will include details like
> security maintenance of multiple Perls, backing out of bad modules,
> finding the best stuff on CPAN, local modification best practices,
> etc. It would be a fat book full of contradictory advice, because,
> after all, TIMTOWTDI. Or it might suggest which technique to use
> in which circumstance, and the level of Perl expertise (available
> at popular prices, consult your local pm.org) needed to accomplish
> various sizes of task.

So this is a page dealing with administrating a Perl installation.

First and foremost thing I can say is if you depend heavily on Perl (or any single piece of technology) build it yourself. This will allow you finer control and faster upgrades than your OS vendor can. Windows is the exception, Strawberry Perl does a much better job packaging Perl and tweaking it for Windows than you can (and if you think you can better, please contribute to Strawberry).

Second, if you do build your own Perl, leave the system Perl alone. On a typical Unix system a lot of things depend on Perl. You don't want them breaking because some crufty old system code is wired to a specific version of perl or module. It will also likely have consequences for things like mod_perl. Build your Perl in its own isolated directory (/usr/local/perl or /opt/local/perl or something) and symlink it into the appropriate bin and man locations (/usr/local/bin and /usr/local/man, for example).

Third, isolate your perl installs so you can have many installed in parallel. Stick 5.8.8 in /opt/local/perl/5.8.8, 5.10.0 into /opt/local/perl/5.10.0, etc. This is handy because upgrading a large, hairy project from one version of Perl and set of CPAN modules to another does not always go well. This allows you to leave an old project alone, using an old version of Perl, while everyone else moves forward. This is not to say you shouldn't fix old projects, but rather to keep old projects that aren't worth fixing from holding everyone else back.

Fourth, keep up to date. This means keeping CPAN modules and perl itself at or near the latest versions. This will incur the occasional breakage as you encounter either intermittent bugs in new versions of CPAN modules, or API changes, or project code that accidentally depends on certain versions of CPAN modules. But it's worth it, because the farther you fall behind the harder it becomes to catch up. As your perl gets older and older, fewer and fewer CPAN modules will work requiring more and more patching to get them working. As your CPAN modules get older, it will require a greater leap to bring them up to date, and more upgrades simultaneously. The sudden upgrade will cause many bugs to happen simultaneously making them take far more time and effort to track down then if they could be dealt with individually. Large upgrades require large effort, time and risks. Small upgrades require small effort, time and risks. The looming risk of a large upgrade will make developers settle for an older, buggier, less capable version and write a work around rather than risk the upgrade. This creates a hidden drag on your project and creates more and more complex code to maintain.

If you do use an undocumented feature, or write a questionable bug work around, or use a private function, test your assumptions. That way when an upgrade breaks your assumption, your tests will tell you immediately rather than having to hunt down the bug caused by some dusty old code written years ago.

can_ok "Some::Module", "_some_private_function";

is Some::Module::foo(undef), 1,     "We depend on foo(undef) returning true";

Fifth, use CPAN modules. Make them easy to install and update. They're worth the maintenance hassle. CPAN is half the power of Perl, and half of being an experienced Perl programmer is knowing CPAN. A project that avoids CPAN modules and reinvents those wheels contains hidden drags. When you take an experienced Perl programmer and drop them into such a project, you are throwing out half their experience. Experience you're paying for. That programmer, and every new programmer, now has to relearn how to do a large pile of things -- on your dime. This makes it take longer for new programmers to become productive. For the programmers, the experience they learn doing it the project's way is not experience they can transfer to another project. And all that extra code has to be maintained by your project's programmers, not for free by some CPAN author. This means your project's programmers are spending their time on commodity, cost-center code rather than the specialized code that makes you money.

The Debian Way

The above guidelines are all well and good but involve a lot of work. The decision is made early to use a custom Perl, for the reasons stated above. The other path is to go with the flow of your operating system and its associated community. You will also get security fixes without as much work.

First, use the system perl. It is more of a known quantity than something that you build yourself. More people are using that version, bugs are more likely to have already been discovered. Also, there are a far greater number of modules available already pre-packaged, for installation in seconds. Likewise, the platform can be replicated very easily - it is contained in just the list of packages you have installed.

Second, use virtualization (such as classic chroot, containers, or even a heavy-weight solution like Xen) to allow you to test your application in the next version of Debian (especially testing) as well as the current version. This step-up pattern has the drawbacks alluded to above; it's more "big bang" than gradual change. However some would regard continual breakages like installing a new version of this-and-that CPAN module as they are released by the maintainers as unacceptable. For the same reason, never dist-upgrade until you have tested your application in the new version already.

Third, use dh-make-perl --build when you need a CPAN package for a particular task that isn't already bundled on debian. Once you are happy with the module, log a bug report for its packaging, perhaps it will show up in the next release of Debian. Do the same thing if you have to build a newer version of an already debianized module. You should probably also review CPAN modules for quality before blindly adding them to your stack. Reuse of code is good - and that module might appear to solve something in a neat way, but if the implementation is shoddy and the author doesn't ever clean it up then you are in effect adding their baggage to your project. A module already being debianized is a good sign; but not necessarily.

As above you should always test your assumptions, in fact you should really have an acceptance test platform. And you should run it against Debian testing as well as your current stable platform.

There is no good answer as to whether a custom-built Perl is superior to using the distribution-built Perl, although certain other vendors have a poor track record when it comes to releasing with a Perl that is a sensible base to code against. There is a good reason this section is called "The Debian Way" and not "The Distro-Perl Way". In any case, this is certainly a path of least resistance, and walked well it is sure and steady.

Debian or custom, I think we can all agree to never, ever, rely on Redhat's Perl (or Centos or any other Redhat derived dist). They've screwed it up many times in the past and are very slow to fix.

contributed by Michael Schwern on Sep 18 4:18pm