If your company is using a slow moving or outdated RPM-based Linux distribution then you likely have an ancient version of Perl (some popular Centos distributions distribute a Perl that is nearly 6 years old). The recommended way to deal with this is to leave the system Perl untouched and package and install a second Perl.

Actually compiling and installing a second Perl is fairly easy. Popular places to install a second perl would be under /opt or under /usr/local. In my example I will install Perl in /opt/perl/<version> where <version> is 5.10.1. This directory structure allows me the ability to install other parallel versions of Perl should I want/need to do that. This blog posting will not cover how to build Perl. That is done adequately enough in the INSTALL file in the Perl source code. One important thing to do is to build with the -Dinc_version_list=none option. This tells the build to not use the @INC from older Perl's in the @INC for this new Perl. This option allows for a complete separation of installation for this new Perl.

When RPM packaging the Perl source code I find it useful to make it provide a virtual package. If your company is named FOO then let's call this virtual package FOO-perl.

  Provides: FOO-perl

Now every Perl package you create will require FOO-perl.

  Requires: FOO-perl

The hard part is creating module packages. Each Perl module RPM you create will have dependencies and it will also provide certain capabilities. By default all Perl code has a capability that looks like this:

  Requires: perl(Module::Bar)
  Provides: perl(Bar::Module)

Unfortunately this perl(...) naming scheme will conflict with the module packages for the system Perl. This is not what you want so what do you do? What I did was this: I copied the two programs in /usr/lib/rpm/ that gather dependencies and provides for a Perl program and placed them somewhere else (for this example let's say /home/user/bin). The two scripts are named perl-requires and perl-provides. I then edited them to return capabilities that look like this:

  Requires: FOO-perl(Module::Bar)
  Provides: FOO-perl(Bar::Module)

If you know Perl this should be trivial and I won't go into the details here.

To get the RPM automatic dependency engine to run the two new scripts you must place the following in your spec file:

  %define __perl_provides /home/user/bin/perl-provides
  %define __perl_requires /home/user/bin/perl-requires

You should also make certain that %_use_internal_dependency_generator is set to a non-zero value (it is set to 1 by default). If this macro returns a zero value the two scripts above will not be run.

Also, each RPM will have a Name: that looks like this:

  Name: FOO-perl-Module-Bar

So now when you build an RPM of a Perl module it will only have provides and requires for your custom Perl install and the RPM will be named FOO-perl-Module-Bar.

So what do you do if you want multiple custom Perl installs? That I don't know about. One way I can think of is to version your FOO label. So instead of capabilities that look like the above you might do this:

  Requires: Foo-perl-5.10(Bar::Module)
  Provides: Foo-perl-5.10(Module::Bar)

And your package would be named Foo-perl-5.10-Module-Bar. Seems complicated but it should work.