On Fri, Feb 22, 2013 at 5:24 PM, Nico Kadel-Garcia <[log in to unmask]> wrote:
> [ Changing thread title to handle Perls of wisdom]
>
> On Fri, Feb 22, 2013 at 11:04 AM, Graham Allan <[log in to unmask]> wrote:
>
>> Just as we here still write most of our support scripts etc in perl, that is
>> also unfashionable now, doesn't mean it's not the best tool for the job (fx:
>> throws bomb and runs away... :-)
>>
>> Graham
>
> 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 ;-)

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

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.

Works a treat.

-- 
natxo