Bug 56348
Summary: | site_perl at end of @INC creates dependency problems | ||
---|---|---|---|
Product: | [Retired] Red Hat Linux | Reporter: | Rich Lafferty <richl> |
Component: | perl | Assignee: | Chip Turner <cturner> |
Status: | CLOSED RAWHIDE | QA Contact: | David Lawrence <dkl> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 7.2 | ||
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2002-02-22 15:32:32 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Rich Lafferty
2001-11-15 22:52:13 UTC
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. |