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
Version-Release number of selected component (if applicable):
Steps to Reproduce:
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
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.