Subject: | |
From: | |
Reply To: | |
Date: | Fri, 22 Feb 2013 11:24:48 -0500 |
Content-Type: | text/plain |
Parts/Attachments: |
|
|
[ 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.
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.
|
|
|