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

[Uwe Ligges]

Hin-Tak Leung wrote:
> --- 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... 

... that cannot be solved easily while we try to make R behave as 
similar as possible on all platforms in order to simplify 
maintainability of the code.

Uwe Ligges



> 
> 
> 
> 
> 
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel