Re^2: Upgrading Core Modules Using CPAN

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]

Comment on Re^2: Upgrading Core Modules Using CPAN - Best Practice? Select or Download Code

Replies are listed 'Best First'.
Re^3: Upgrading Core Modules Using CPAN - Best Practice? by stocks29 (Acolyte) on Oct 03, 2008 at 15:06 UTC
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]	[reply] [d/l]

Replies are listed 'Best First'.

Re^3: Upgrading Core Modules Using CPAN - Best Practice?
by stocks29 (Acolyte) on Oct 03, 2008 at 15:06 UTC

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]

[reply]
[d/l]