[sf-perl] Third party Perl rpms for enterprise Linux distros

Fred Moyer fred at redhotpenguin.com
Wed May 11 13:37:14 PDT 2011

A repeating theme that I have been seeing with enterprise scale perl
applications is that deploying rpm based versions of Perl modules in
production environments has several problems that seem to remain

For instance, if you are running a Centos/Fedora production
environment, and your application depends on a certain version of
DBIx::Class (used as an example), the following events may happen:

1) An update to that module version may become available which is
incompatible with the version of DBIx::Class that your application is
tested with.

2) If you use CPAN, perlbrew, or cpanminus to install a specific
version of a module, it may cause compatibility issues with modules
installed via yum or rpm (this has been documented publicly by the
Fedora Perl module maintainer).

3) If you need to make a slight change to a module which is installed
as an rpm, that may cause problems as well.

4) Updating a module may break another part of the system which
depended on a specific version, and now you have a broken Linux box.

In addition, there is the consideration that Fedora/Centos ships a
threaded version of Perl as the system perl binary, and that can be
10-25% slower than a non-threaded version (from benchmarks I have

My thinking has gotten me to the point where I believe that installing
a separate perl binary in /opt or somewhere else can solve all of
these problems.  However, building a perl rpm takes some elbow grease,
and additionally one would need a set of rpms built against that
binary that could be managed via yum/rpm.  ActiveState offers their
ppm based modules as an alternative solution, but from what I have
read their set of architectures and support is somewhat limited - you
can't roll a newer ppm version of a module if you really need it.

Has anyone seen a good solution to this problem?  The Ovid module on
CPAN has some rpm generation functionality one can work with, but it
seems that having a non-system perl rpm is needed as a prerequisite.

More information about the SanFrancisco-pm mailing list