[CentOS] Setup a devel environment for perl modules

[Brian Mathis]

On Tue, Apr 1, 2014 at 5:27 PM, <m.roth at 5-cent.us> wrote:

> Brian Mathis wrote:
> > On Tue, Apr 1, 2014 at 2:50 AM, C. L. Martinez <carlopmart at gmail.com>
> > wrote:
> >>
> >>  This is an interesting thread:
> >>
> >>  http://lists.centos.org/pipermail/centos/2014-April/141871.html
> >>
> >>  about the problems you can find building perl modules for CentOS
> >> releases (new or old).
> >>
> >>  I agree with John R. Pierce: cpan is very very bad tool ( in fact, I
> >> hate it) to build perl modules for CentOS systems, breaks all other
> >> perl modules. I need to use several perl modules in several servers in
> >> my dept. and after some tests, I migrate to FreeBSD due to easy
> >> install perl modules with poudriere suite.
> >>
> >>  But, anyone knows if it is possible to build a confident devel
> >> environment under  CentOS with some tool to build rpm's perl modules
> >> without breaking anything in CentOS systems??
> >>
> >>  Maybe, it is a good idea to create a CentOS Perl SIG :))
> >
> > Just today I managed to get a modern perl (5.18.2) installed on CentOS 5
> > using perlbrew.  This gives you a complete perl environment in a private
> > location where you can install modules without impacting the system perl.
> > Normally I'm all for using pre-packged RPMs, but the C5 perl is so out of
> > date that it pays off to do it this way instead.
> >
> > I ran into an issue with the setup script from the web site, and this
> > seems to have worked around it:
> <snip>
>


> Right. And, um, don't forget to update that local userspace perl, and its
> modules regularly. And don't wait for the notice of updates or security or
> bugfixes, since there aren't any....
>
>        mark "yummmmmm"
>


Mark,

Yes, this is a good point.  In a setup like this you are taking
responsibility for updates and patching yourself, just like you would for
any other set of libraries you use to develop an application.  It becomes
local to your application and not something you can rely on the operating
system to provide, much like many java applications now come with a full
version of the JRE they need to work included.

This is the tradeoff you make, but it's not necessarily bad.  You can use
the OS and patching infrastructure as the foundation for your app, then use
whatever you need to actually accomplish your business goal.  If that one
part of the system needs to be customized, then so be it.  After all,
that's the reason you're running the server in the first place.


❧ Brian Mathis