[Rd] R --vanilla for install/remove/shlib(Re: R 2.8->2.9 change that breaks some upgrade scenarios)

[Martin Maechler]

>>>>> "HL" == Hin-Tak Leung <hintak_leung at yahoo.co.uk>
>>>>>     on Thu, 30 Jul 2009 08:59:01 +0000 (GMT) writes:

    HL> --- On Thu, 30/7/09, Martin Maechler <maechler at stat.math.ethz.ch> wrote:
    >> I'm not sure this addresses all the problems that your
    >> patch
    >> tried to fix,
    >> but in any case, your patch re-installing the --vanilla
    >> behavior
    >> unconditionally (without the .libPaths()[1] detection) was
    >> not 
    >> suffificient.

    HL> But I think .libPaths should not be _implicitly_ user-/site- overridded - afterall, non-standard locations are already catered for with the -l option (which presumbably does the same thing as declaring R_LIBS, just explicitly).

We are talking *only* about the case where no '-l' (or
'lib.loc') was specified, and the default has always been to
take the first entry in  .libPaths() .... [ with all its
problems when that is not writable, but that's a different story]


    HL> This is analogous to installing system libraries and run-time relocation - while people do install binaries and libraries in non-standard locations and customize their $PATH and $LD_LIBRARY_PATH to reflect that either at the user- or site- level, it would be quite strange to allow ./configure or other equivalent software building tools to peek at the first part of PATH or LD_LIBRARY_PATH and put executables in the former and libraries in the latter... That's almost anarchy :-).

The comparison is interesting, and slightly off I think:
Again, we are only talking about the case when there's *no*
default library location specified for package *installation*.

HOWEVER,
the case I mentioned, where I have scenarios where I was able to
use
	'R_LIBS=...:...:....  R CMD check <mypkg>'

using non-default library locations, not for installation
(because that would be  <mypkg>.Rcheck  anyway), but for
searching of package *dependencies* of <mypkg>
is also something that has stopped working in the current
R-devel, because it uses our site-wide Rprofile and that sets
R_LIBS differently itself.

--

Anyway, I think it would not be a bad course to still *allow* 
"vanilla-INSTALL"  but keep the current R-devel default
behavior.
But maybe we can find something better.
(and hopefully other R core members will explain more clearly
 why they think it was "the correct" default behavior to obey
 site-wide and user-specific  Rprofile  settings)

Martin