Perl Modules: CPAN vs Yum

Tod Hansmann at
Tue Jul 3 16:57:02 MDT 2012

On 7/3/2012 4:30 PM, Jared Smith wrote:
> On Tue, Jul 3, 2012 at 1:14 PM, Tod Hansmann< at>  wrote:
>> Why don't the devs just include any libraries they want inside the app
>> they want you to deploy.
> There are several compelling reasons not to bundle libraries, but the
> one that sticks out the most in my mind is when a security problem is
> found in one of the bundled libraries.  You essentially have to go
> through and and make sure that each bundled copy of the library gets
> updated with the security patch.  If you instead link to one single
> library, once that's updated, you know that every user of that library
> is now secure.
> A second reason is forking.  When you bundle libraries, it becomes
> really tempting to fork the bundled library and add your own patches
> to it, rather than pushing patches upstream.
> Trust me -- no sysadmin worth his salt wants a dozen different
> versions of a single library in various places on a machine, let alone
> a dozen forked copies of said library.  This is why the packaging
> guidelines in many distributions (such as Fedora) prohibit bundled
> libraries
So, I agree with your reasoning here, but all the problems you just 
listed also apply to mixing OS packages (debs, rpms, etc) and CPAN 
modules.  The difference is that keeping the app working when a security 
patch needs to be applied is now the devs' sole problem, as opposed to a 
problem for both the devs' AND the sysadmin, which is never a good 
workflow design.

Not to mention, I don't know how it is with perl, but with python it's 
pretty easy to just flip a --prefix option and install to where you 
want, and make sure your app is the only thing using it.

As for forking, that's not a bundling problem, that's a poor development 
team problem.  With perl and their ilk especially, you don't have to 
fork to extend functionality of a module.  If the dev team wants to fork 
someone else's code, they are literally asking for more work.

-Tod Hansmann

More information about the PLUG mailing list