Bug 79916 - Reversed @INC
Summary: Reversed @INC
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: perl
Version: 8.0
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Warren Togami
QA Contact: David Lawrence
URL: http://www.debian.org/doc/packaging-m...
Depends On:
TreeView+ depends on / blocked
Reported: 2002-12-18 00:57 UTC by Rob Brown
Modified: 2007-04-18 16:49 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2005-05-28 07:15:32 UTC

Attachments (Terms of Use)

Description Rob Brown 2002-12-18 00:57:34 UTC
Description of problem: 
Perl core modules always shadow the modules in the 
site and vendor directories making it extremely 
difficult to upgrade newer versions of core modules 
from CPAN. 
Version-Release number of selected component (if applicable): 
How reproducible: 
Steps to Reproduce: 
perl -V 
Actual results: 
Expected results: 
Additional info: 
This isn't just for RH 8.0 or perl 5.8.0.  You've 
been doing it the same way in all your previous 
distributions and all the other perl versions too! 
Why do you think the /vendor_perl/ and /site_perl/ 
directories are in the @INC to begin with?  It is 
so modules can be installed there to easily shadow 
undesired versions of currently installed modules. 
For the broken way that you have it now, if someone 
wants to upgrade one of the perl modules that is 
part of the perl rpm, "rpm --replacefiles" has to 
be done (which is ugly and irreversable) or else 
rebuild the entire perl rpm itself which is far 
more trouble than it's worth.  You did it exactly 
opposite from debian's suggested policy for 
packaging perl: 

Comment 1 Chip Turner 2002-12-18 02:35:06 UTC
actually site_perl should probably be in front of vendor_perl, so that per-site
configuration overrides both core packages and vendor-provided packages.

however, this was discussed on perl5-porters before 5.8.0 shipped:



I very much agree this would be a good thing, but until upstream does it
similarly, I am hesitant to change in a rather incompatible way.  however, if it
does change upstream for 5.9.0, I will consider backporting the patch.  I would
like to see a decision that the perl community will back, though, before
implementing it for RH only.

specifically, please note that RH does -not- change the @INC ordering.  I agree
with debian's policy, but what we ship is the upstream perl 5.8.0's default policy.

Note You need to log in before you can comment on or make changes to this bug.