R --vanilla for install/remove/shlib(Re: R 2.8->2.9 change that breaks some upgrade scenarios)
--- On Thu, 30/7/09, Martin Maechler <maechler at stat.math.ethz.ch> wrote:
"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)
But there is always a shipped default? $R_HOME/library , and I seem to recall for non-admin users, $HOME/R/<arch> . .libPath() is $R_HOME/library on R --vanilla . If the user or site admin choose a configuration to prepend .libPath() with a customization via Rprofile/R_LIBS, it stands to reason that he/she should also do -l for installation? (or rather, it should happen the other way round - if one choose to install, *consciously*, elsewhere than the default, than Rprofile/R_LIBS is required) Nonetheless, I think we are drifting a little. the original problem was that it is not possible to upgrade/overwrite a package and its associated resources like its namespace when that package is loaded. Maybe the correct solution is to unload the said package, unregister the dlls/shared-libraries, and unload a namespace on installation. I seem to recall that there are some issues about dll unloading on windows, but that's a technicality...