in reply to Re^2: Upgrading Core Modules Using CPAN - Best Practice?
in thread Upgrading Core Modules Using CPAN - Best Practice?

This does appear to be a third possible solution, but the CPAN perldoc makes me a little weary about it. Specifically: In fine tuned environments UNINST=1 can cause damage.

1) I installed a new version of module X but CPAN keeps saying, I hav +e the old version installed Most probably you do have the old version installed. This can happ +en if a module installs itself into a different directory in the @INC + path than it was previously installed. This is not really a CPAN.pm +problem, you would have the same problem when installing the module m +anually. The easiest way to prevent this behaviour is to add the argu +ment UNINST=1 to the make install call, and that is why many people a +dd this argument permanently by configuring o conf make_install_arg UNINST=1 2) So why is UNINST=1 not the default? Because there are people who have their precise expectations about + who may install where in the @INC path and who uses which @INC array +. In fine tuned environments UNINST=1 can cause damage.