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

Chris Weyl cweyl at alumni.drew.edu
Thu May 12 10:15:10 PDT 2011

On Wed, May 11, 2011 at 1:37 PM, Fred Moyer <fred at redhotpenguin.com> wrote:

> 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
> unsolved.

This does come up quite a bit: at my last, current, and next employer, even
:)  Some of the problems here are distro/rpm, some are Perl/CPAN.

Distro problems (from a developer perspective, not meant to be exhaustive):

* no control over how perl is built
* CPAN packages installed outside of RPM to the system perl site shoot RPM
metadata dependency to heck
* dependent packages are not retested when a newer package is built (aka: no
smoke testing) (e.g. perl-Moose is upgraded, but perl-MooseX-* aren't
* RPM's automatic Perl metadata generation is geared towards the system perl
only (resulting in spurious metadata if not disabled and an independent Perl
package is built)

CPAN problems:

* versioning only specifies a lower bound (e.g. currently not possible to
specify "won't work with Moose > 1.99")

I do[1] a bit of work with Fedora's Perl SIG, as well as in-house for our
servers.  On the Fedora side I've introduced RPM dependency filtering (for
cleaner RPM metadata) and automatic "-tests" subpackages to provide a way,
post-build, to test the installed package.  To date, only the dependency
filtering code has really taken off; I haven't had the time to drive the
-tests subpackages the way I want.

At $work, I've taken to building independent Perl RPMs: put them somewhere
convenient (e.g. %global _prefix /usr/perls/5.xx.yy),  disable metadata
generation, etc.  This works, and is pretty straight-forward, but then what
to do with CPAN packages?  Do we build and install one-by-one as we do in
Fedora, or do we try to cluster them in larger RPMs?  How do we handle
dependency metadata in a way that 1) works(!), 2) doesn't conflict with the
system perl, and 3) makes sense?  How can we take advantage of the (very)
large number of CPAN RPMs already created over in Fedora?

I've also started tinkering with sitecustomize.pl.  This is a little known
feature that causes a properly named/located script to be invoked "very
early" when perl is invoked; I'm looking at it mainly to fiddle with @INC so
we can stay away from other, erm, less-desirable hacks.  It's enabled when
perl is compiled with the -Dusesitecustomize option.

Also...  I really, really miss the git plugin for cpanminus.  Being able to
maintain a stack of modules outside for per-application purposes was quite
nice :)


I do find myself going back and forth, but the basic things I now try to
stick to are:

1) don't mess with the system perl -- your SAs or your enterprisey vendor
will hate you
2) use RPM for the biggies -- but maintain a parallel set of packages not
dependent or conflicting with system perl
3) don't use automatic metadata generation, but...
4) use RPM metadata, even if you have to manually add it
5) provide the standalone cpanm/perlbrew scripts as part of the core perl
package (pref. in a subpackage)


[1] "once and future" work might be a more accurate statement...  I'm
starting to get back into it, but my Real Life intruded rather forcefully
last summer and pretty sharply constrained my free time.

Chris Weyl
Ex astris scientia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.pm.org/pipermail/sanfrancisco-pm/attachments/20110512/ec9c4974/attachment-0001.html>

More information about the SanFrancisco-pm mailing list