This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 79916 - Reversed @INC
Reversed @INC
Status: CLOSED UPSTREAM
Product: Red Hat Linux
Classification: Retired
Component: perl (Show other bugs)
8.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Warren Togami
David Lawrence
http://www.debian.org/doc/packaging-m...
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-12-17 19:57 EST by Rob Brown
Modified: 2007-04-18 12:49 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-05-28 03:15:32 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Rob Brown 2002-12-17 19:57:34 EST
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): 
ALL 
 
How reproducible: 
Always 
 
Steps to Reproduce: 
perl -V 
 
Actual results: 
  @INC: 
    /usr/lib/perl5/5.8.0/i386-linux-thread-multi 
    /usr/lib/perl5/5.8.0 
    /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi 
    /usr/lib/perl5/site_perl/5.8.0 
    /usr/lib/perl5/site_perl 
    /usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi 
    /usr/lib/perl5/vendor_perl/5.8.0 
    /usr/lib/perl5/vendor_perl 
    . 
 
 
Expected results: 
  @INC: 
    . 
    /usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi 
    /usr/lib/perl5/vendor_perl/5.8.0 
    /usr/lib/perl5/vendor_perl 
    /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi 
    /usr/lib/perl5/site_perl/5.8.0 
    /usr/lib/perl5/site_perl 
    /usr/lib/perl5/5.8.0/i386-linux-thread-multi 
    /usr/lib/perl5/5.8.0 
 
 
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: 
 
http://www.debian.org/doc/packaging-manuals/perl-policy/
Comment 1 Chip Turner 2002-12-17 21:35:06 EST
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:

http://archive.develooper.com/perl5-porters@perl.org/msg82525.html

specifically:
http://archive.develooper.com/perl5-porters@perl.org/msg83707.html

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.