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): How reproducible: Always Steps to Reproduce: 1. perl -V Actual Results: /usr/lib/perl5/5.6.0/i386-linux /usr/lib/perl5/5.6.0 /usr/lib/perl5/site_perl/5.6.0/i386-linux /usr/lib/perl5/site_perl/5.6.0 /usr/lib/perl5/site_perl Expected Results: /usr/lib/perl5/site_perl/5.6.0/i386-linux /usr/lib/perl5/site_perl/5.6.0 /usr/lib/perl5/site_perl /usr/lib/perl5/5.6.0/i386-linux /usr/lib/perl5/5.6.0 Additional info:
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 Getopt::Long. 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 versions anymore. 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: @INC: /usr/lib/perl5/5.6.1/i386-linux /usr/lib/perl5/5.6.1 /usr/lib/perl5/site_perl/5.6.1/i386-linux /usr/lib/perl5/site_perl/5.6.1 /usr/lib/perl5/site_perl/5.6.0/i386-linux /usr/lib/perl5/site_perl/5.6.0 /usr/lib/perl5/site_perl/5.005/i386-linux /usr/lib/perl5/site_perl/5.005 /usr/lib/perl5/site_perl /usr/lib/perl5/vendor_perl/5.6.1/i386-linux /usr/lib/perl5/vendor_perl/5.6.1 /usr/lib/perl5/vendor_perl This should solve the problem you see.