If it didn't, you wouldn't be able to "seamlessly" upgrade CPAN (the CPAN shell always checks to see if there's a newer version available).

So, I don't have an answer. I always assumed it would just work (and it always has for me).

This means that putting Makefile.PL args in CPAN::Config may work for some modules but not for others.

Could you point out an example module that doesn't allow to configure its install destination?  I mean, if this is true, how would CPAN.pm then achieve to install the module in the 'site' subtree, as you're saying? (just wondering)

In the cpan shell, type the following command with the specific path where you need to update the core modules cpan> o conf makepl_arg PREFIX='<dir path>' cpan> o conf commit Default lib path will be changed after this command.. Lemme know if it works

Getting the modules into the PREFIX path is not the problem. It is ensuring that the modules is installed in the correction location w/in the PREFIX path that is the problem:

PREFIX=/usr/local/perl5.8.6

/usr/local/perl5.8.6/lib/5.8.6/sun4-solaris/Errno.pm (core)
/usr/local/perl5.8.6/lib/site_perl/5.8.6/Errno.pm (cpan)
[download]

First off, thanks for all the feedback so far. 'Errno' is an example of one such module. This modules was installed as a core module to: /usr/local/perl5.8.6/lib/5.8.6/sun4-solaris/Errno.pm

When I use CPAN to install this module, it defaults to installing in: /usr/local/perl5.8.6/lib/site_perl/5.8.6/Errno.pm

I tried to specify the following arguments that would be passed to Makefile.PL to adjust the install path: 'makepl_arg' => qq[INSTALLDIRS=perl}

With this makepl_arg set, the module still installs into the same directory.

I did run across a post that suggested specifying the INSTALLPRIVLIB to the value of $Config{archlibexp} (while 'use'-ing Config), which does seem to tell the module to install into the correct location.

So, if specifying the INSTALLPRIVLIB makepl_arg is a possible solution, the questions that remain are:

• Do all core modules specify INSTALLDIRS=perl as their default location? If not, we would have to add this to CPAN::Config which may cause issues for non-core modules.
• If I specify INSTALLPRIVLIB=$Config{archlibexp} in CPAN::Config, could this cause problems for some modules?

Lastly, getting back to the original question, regardless of how it is done, is clobbering the old (core) version with the new (cpan) version of the module the recommended solution? Or would anyone suggest the @INC overlays?

cpan> o conf mbuild_install_arg UNINST=1
cpan> o conf make_install_arg '--uninst 1'

cpan> o conf init

You appear to have them the wrong way around, it should be:

cpan> o conf mbuild_install_arg '--uninst 1'
cpan> o conf make_install_arg UNINST=1
[download]

Similar settings in CPANPLUS are:

CPAN Terminal> s conf buildflags uninst=1
CPAN Terminal> s conf makeflags UNINST=1
CPAN Terminal> s save
[download]

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.
[download]

make alone puts all relevant files into directories that are named by the macros INST_LIB, INST_ARCHLIB, INST_SCRIPT, INST_MAN1DIR and INST_MAN3DIR. All these default to something below ./blib if you are not building below the perl source directory. If you are building below the perl source, INST_LIB and INST_ARCHLIB default to ../../lib, and INST_SCRIPT is not defined.

The install target of the generated Makefile copies the files found below each of the INST_* directories to their INSTALL* counterparts. Which counterparts are chosen depends on the setting of INSTALLDIRS according to the following table:

                             INSTALLDIRS set to
                       perl        site          vendor

             PERLPREFIX      SITEPREFIX          VENDORPREFIX
INST_ARCHLIB   INSTALLARCHLIB  INSTALLSITEARCH     INSTALLVENDORARCH
INST_LIB       INSTALLPRIVLIB  INSTALLSITELIB      INSTALLVENDORLIB
INST_BIN       INSTALLBIN      INSTALLSITEBIN      INSTALLVENDORBIN
INST_SCRIPT    INSTALLSCRIPT   INSTALLSITESCRIPT   INSTALLVENDORSCRIPT
INST_MAN1DIR   INSTALLMAN1DIR  INSTALLSITEMAN1DIR  INSTALLVENDORMAN1DI
+R
INST_MAN3DIR   INSTALLMAN3DIR  INSTALLSITEMAN3DIR  INSTALLVENDORMAN3DI
+R
[download]

Won't putting INSTALLDIRS=>'perl' in CPAN::Config force all modules into the "core" path, even those that are not core modules?

Whats your point?

You really needn't worry, all CORE modules available as separate downloads on CPAN already know how to get installed in lib instead of site/lib :)

That is what I thought too, but then why did I end up with two versions of some modules installed when upgrading from CPAN?

/usr/local/perl5.8.6/lib/5.8.6/sun4-solaris/Errno.pm (core: 1.09_00)
/usr/local/perl5.8.6/lib/site_perl/5.8.6/Errno.pm (cpan: 1.10)
[download]

Congratulations, you've found a bug, report it to whomever put Errno on cpan :)