SCIENTIFIC-LINUX-USERS Archives

February 2013

SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Nico Kadel-Garcia <[log in to unmask]>
Reply To:
Nico Kadel-Garcia <[log in to unmask]>
Date:
Fri, 22 Feb 2013 11:24:48 -0500
Content-Type:
text/plain
Parts/Attachments:
text/plain (29 lines)
[ 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.

ATOM RSS1 RSS2