Red Hat Bugzilla – Bug 56348
site_perl at end of @INC creates dependency problems
Last modified: 2007-04-18 12:38:18 EDT
From Bugzilla Helper:
User-Agent: Mozilla/4.75 [en] (X11; U; Linux 2.2.16-22 i686)
Description of problem:
Since @INC contains the standard include directories before the
site_perl ones, newer versions of modules installed into site_perl
aren't used (since the older version shipped with Perl is encountered
first). This leads to difficult-to-resolve dependency problems, since
installing a newer version of the module requires either overwriting or
removing the version of the module that shipped with Perl.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. perl -V
Actual Results: /usr/lib/perl5/5.6.0/i386-linux
Expected Results: /usr/lib/perl5/site_perl/5.6.0/i386-linux
Hrm, this doesn't work. I'll use Getopt::Long as an example; let's say that
you have a program "foo" installed via RPM that depends on the Getopt::Long
shipped with perl, and another program "bar" that requires a newer version of
The new version of Getopt::Long would have to be installed into site_perl if
installed via RPM, otherwise it would conflict with perl. The way I originally
thought about this is that because of that conflict, site_perl needs to be
first, so that "bar" will find the library it needs.
But that breaks "foo", and the only way that "foo" can require a particular
version of Getopt::Long is to depend on the correct perl rpm. If site_perl
is first in @INC, depending on the perl rpm isn't reliable for module
It seems to me that the only way to solve this is to compartmentalize
the perl packages more, so that instead of depending on perl, "foo" would
depend on perl-Getopt-Long, and then you could upgrade perl-Getopt-Long,
and foo would either be content or complain when you tried.
Peter Jones mentioned that you were considering a sysadmin-configurable
@INC; I'm not sure that's a solution either, because it'll still break
dependencies in the same way as universally changing @INC. Of course,
setting $PERL5LIB does the same thing, but since it's user-by-user, I
think $PERL5LIB is a reasonable "if it breaks, you get both pieces" case
that can be ignored.
This is not to say that I *expect* the perl rpm to be broken up into its
components, but I'm not sure that there's another solution that's more
graceful/effective than just saying "If you want it to behave differently,
set $PERL5LIB, or 'use lib'".
I've no idea if this makes sense written out, but it makes sense to me! :-)
the perl in the latest skipjack beta should have @INC now split. we've moved
all of our modules to the vendor_perl tree, which comes after site_perl in @INC:
This should solve the problem you see.