Packaging a new version of a core perl module

Todd Rinaldo toddr at
Sat Nov 20 17:48:23 UTC 2010

On Nov 19, 2010, at 12:37 PM, Stuart D Gathman wrote:

> On 11/17/2010 07:08 PM, Tim Mooney wrote:
>> Your only other option is to override how the perl module installs itself
>> at package build time, so that it goes into site_perl or some other directory, and then make certain that any modules that "use foo" get your version
>> first, rather than the older version that's part of core perl.  Also not
>> easy.
> IMO, this is the best option.

Unless your perl > 5.12, the modules distributed with perl come first in the search path. Installing them to site_lib will not replace the original version. 5.12 fixed this. Your scripts would have to mess with @INC and/or you could look into local::lib ( as a possible solution.

Personally I've given up on using the perl that comes with the OS. We're moving towards using and maintaining a custom perl outside of the OS perl. There are just too many issues fighting with yum and system dependencies for system perl to be a good choice.


More information about the Rpm-list mailing list