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

[Fred Moyer]

On Wed, May 11, 2011 at 2:14 PM, Joseph Brenner <doomvox at gmail.com> wrote:
> Slightly longer:  I believe one of the selling points of
> Module::Install was that it would let you package up all your
> dependencies in one easily portable package,

That sounds enough like the purported portability of Java that it
makes me skeptical.

> Long-winded editorial: I think that this is a reflection of a general
> problem with version management that the linux distros haven't really
> confronted: you don't always want just one version of something, in
> fact you often want to have multiple versions available (if only for

I'm not necessarily after being able to have multiple versions of Perl
modules available, just a second 'application' install of perl as
opposed to the system installed perl.  Using the system perl brings up
many problems that cannot be easily solved.

Imagine if we were working on a Python application, and used the
system python binary for running applications.  Upgrades to the system
python binary and associated modules would certainly wreak havoc on
yum and the many other system level tools that use python.  So perhaps
we have it somewhat easier by working with Perl in that the other
applications used by the Linux distro aren't as dependent on Perl.

> (1) I suspect that Fred is right that to be perfectly bullet-proof
> about this one would need to create a custom package to install a
> particular perl binary, but I agree that that's a pain... and I'm not
> sure it's a necessary pain.  Wouldn't it be easier to test against a
> half-dozen or so major perl versions so you don't need to worry about
> the system binary?

Perhaps it would be easier, but what I'm after here is decoupling the
dependencies between the system perl modules and modules needed by the
application.  To do that completely, you need a second perl binary
which is used only by your application.  Packaging that into an rpm is
painful, but it is only painful once per Centos/Fedora release.

> (2) When you start worrying about the versions of various modules
> you're using, I think you get into a combinatoric explosion that makes
> it very difficult to test all possibilities before shipping.   I would

I'm only worried about the versions in their interaction with system
Perl modules.  Say the Fedora Perl maintainer updates JSON from 1.4 to
2.x (an example from memory).  It has been tested with applications
that ship with Fedora, but breaks your application.  This upgrade is
done by your IT department because there was a security update
released.  Does anyone from IT notice this detail and check with
development before hand?  Probably not in most cases, as the problem
has not yet manifested itself, and preventative checks such as this
can be too numerous and ephemeral to be practical.

It looks like ActiveState comes closest to what I'm looking for here
(found out they do have rpms), but their implementation seems to
target a wide variety of platforms (windows, os x, solaris, linux) at
the cost of having a lot of recent modules available.

This is assuming of course that most people running multi server Perl
applications are using Fedora / Centos / RHEL.  I think that is a
pretty good bet though.