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

[Hin-Tak Leung]

--- 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...