On Sat, Feb 23, 2013 at 7:46 AM, Natxo Asenjo <[log in to unmask]> wrote:
> On Fri, Feb 22, 2013 at 5:24 PM, Nico Kadel-Garcia <[log in to unmask]> wrote:

>> As long as you package the modules, you can get away with this. One of
>> the painful difficulties comes when people put "cpan build Foo::bar"
>> for the Foo:::Bar module to enable features on their deployed systems,
>> built right into their  config scripts or testing tools or instlalers,
>> and wind up displacing system versions of core utilities. This can,
>> and has, included accidentally replacing Perl itself at various times
>> to get various updated modules.
>
> yes, people seem to never have heard of local::lib and get themselves
> in terrible troubles ;-)

*Tell* me about it. I spent a great deal of time a few years back
backporting Apache 1.3 to one of the moral equivalents of Scientific
Linux 4, because the oroginal software relied on the old mod_perl
package. *dozens* of dependencies.

>> Fortunately, for SL and other upstream vendor based modules, it's
>> often possible to find them in 3rdparty repositories, especially loo,
>> in Fedora for backporting, or to use tools like "cpan2rpm" or
>> "cpanspec" to build RPM's for them which you can deploy in an internal
>> yum repository or for direct installation via cfengine or puppet.
>> similar techniques work well for PHP and Ruby modules as well.
>>
>> I actually publish a whole stack of these over at
>> https://github.com/nkadel/. And i'm happy to show other people how to
>> set up build environments for that.
>
> it's cool to see what you have done, but really, these days building
> custom Perls and deploying them side by side system Perl is a very
> easy: perlbrew, cpanminus, cpan-outdated. You get the best of both
> worlds. New modern Perl goodies for modern times, legacy Perl for
> older enterprise systems.

It can get..... awkward. You hve to essentially mantain a separate
toolchain, and lose the dependency tracking and version tracking that
you get with RPM or any sane package management sysstem.

> We deploy several Perls to our environments and adding new modules is
> just a cpanm away in one place, the changes get picked up and are
> distributed to the hosts.

And *that* is exactly the problem. Deployment is easy. Cleanup of old
components, especially as different versions of different packages
pick up the same module names? Not so easy.

> Works a treat.

Until it doesn't, which I'm afraid I've encountered headlong. The
problem isn't making your own, local toolchains, it's the hidden
module dependencies. I encountered this with mod_perl some years back:
a project needed to use an older mod_perl, and building the toolchain
from CPAN led to circular dependencies each calling the most recent
version of the other components, which depended on other recent
components, which depended on a more recent version of mod_perl.

Hilariity ensued. I had to build RPM's for *each individual module",
rename them from "perl-foo-bar" to "project-perl-foo-bar" to get them
out of the yum update chain, or I'd have had to rewrite all the
original source code to do what you originally suggested: look in a
locally managed directory, first.