Perl Modules: CPAN vs Yum

Tod Hansmann at
Tue Jul 3 11:14:55 MDT 2012

On 6/29/2012 10:10 PM, Jacob Albretsen wrote:
> Hi all,
> I'm not a Perl guy, but the devs at my company have asked me to put together
> an application server (CentOS 5) for them which runs a Perl application.  In
> the past before they hired me as the sysadmin, it was thrown together as
> quickly as possible and not documented very well because they needed to get
> back to coding.  I'm now wanting to figure it out and document it correctly and
> automate the process as much as possible with Kickstart and Salt.
> The devs handed me a long list of needed Perl modules.  I've messed with CPAN
> before so I've spent two days playing with it again trying to install modules
> on some VMs and getting a feel for what I'm up against and finding a headache
> or two along the way.  I've also discovered that a good portion of these
> modules are available in either the CentOS base repository for EPEL.  However
> there are a number I would still need to use CPAN to get installed.
> I've noticed that "instmodsh" will only list modules installed by CPAN, but
> not by Yum. To get all modules I have to use more elaborate methods.
> So the question is.... is it a good practice to mix the two ways to install
> Perl modues?  Will I run into issues mixing the two?
Why don't the devs just include any libraries they want inside the app 
they want you to deploy.  Then the app isn't botched when a sysadmin who 
doesn't know all the nuances of the apps (read: any sysadmin ever) needs 
updates a teeny library?  You can still get lists of what's installed 
and check for security updates you think are important enough to get 
them to update them in the app and redeploy after they run their testing.

This also has the advantage of making the app completely portable as 
long as it has a compatible version of perl installed.  It's the best of 
all worlds, and the devs are doing it anyway on their own machines.

Anyway, that's just my thought on it.  Not really "best practice" or 

-Tod Hansmann

More information about the PLUG mailing list