Hide Forgot
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/
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.