[Rd] R --vanilla for install/remove/shlib(Re: R 2.8->2.9 change that breaks some upgrade scenarios)
maechler at stat.math.ethz.ch
Thu Jul 30 12:35:24 CEST 2009
>>>>> "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
>> tried to fix,
>> but in any case, your patch re-installing the --vanilla
>> unconditionally (without the .libPaths() detection) was
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*.
the case I mentioned, where I have scenarios where I was able to
'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
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)
More information about the R-devel