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 (http://search.cpan.org/perldoc?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. Todd _______________________________________________ Rpm-list mailing list Rpm-list@xxxxxxxxxxxxx http://lists.rpm.org/mailman/listinfo/rpm-list
