Updating perl modules inside the base perl package

[Robin Norwood]

"Ian Burrell" <ianburrell at gmail.com> writes:

> On 9/8/06, Nigel Metheringham <Nigel.Metheringham at dev.intechnology.co.uk> wrote:
>> Ian Burrell wrote:

[...]

> Those both have separate distributions on CPAN in addition to being
> included in perl.  Separate packages could be built from the newer
> releases.  Unfortunately, there is a problem in getting them used.  On
> RHEL 4 is that the include directories go (taking out multiple
> versions and binary directories):
>
> /usr/lib/perl5/5.8.5
> /usr/lib/perl5/site_perl/5.8.5
> /usr/lib/perl5/vendor_perl/5.8.5
>
> If you install the separate packages in vendor_perl (this requires
> special options while building), they won't be used.  If you install
> them in /usr/lib/perl5/5.8.5 (the default), the files will conflict
> with the perl RPM.  The FC5 perl fixes the problem by changing the
> order so that the vendor_perl directory comes first.
>
> /usr/lib/perl5/site_perl/5.8.8
> /usr/lib/perl5/vendor_perl/5.8.8
> /usr/lib/perl5/5.8.8
>
> My impression is that the RHEL 4 perl 5.8.5 is binary compatible with
> the FC5 5.8.8.  This is controlled by the "perl(:MODULE_COMPAT_5.8.3)"
> requirements.  And by the default INC including the
> 5.8.3/i386-linux-thread-multi and later direcrtories.

Using site_perl and/or vendor_perl is certainly the right way to fix
this for releases that have the @INC order right.  I'm not sure what to
recommend to the OP besides either rebuilding the perl package, or
possibly a dirty hack like:

o Have 'your' versions of the modules installed in a directory
  (/foo/bar)
o Put a 'use lib "/foo/bar"' at the top of all the scripts

Since use lib prepends to @INC, that 'should work'.

Anyone have a better, or at least 'less bad', idea?

-RN

-- 
Robin Norwood
Red Hat, Inc.

"The Sage does nothing, yet nothing remains undone."
-Lao Tzu, Te Tao Ching