>>>>> "HL" == Hin-Tak Leung <hintak_le...@yahoo.co.uk>
>>>>> on Thu, 30 Jul 2009 08:59:01 +0000 (GMT) writes:
HL> --- On Thu, 30/7/09, Martin Maechler <maech...@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
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
