[R-sig-Fedora] R 2.12.0 in Fedora Updates Testing

[Tom "spot" Callaway]

On 11/07/2010 11:33 PM, Paul Johnson wrote:
> Even though nobody but me seems to care, I think it is better to do
> what Ubuntu does, where Renviron has at the end
> 
> R_LIBS_USER=${R_LIBS_USER-'~/R/x86_64-pc-linux-gnu-library/2.12'}
> # edd Apr 2003  Allow local install in /usr/local, also add a directory for
> #               Debian packaged CRAN packages, and finally the default dir
> # edd Jul 2007  Now use R_LIBS_SITE, not R_LIBS
> R_LIBS_SITE=${R_LIBS_SITE-'/usr/local/lib/R/site-library:/usr/lib/R/site-library:/usr/lib/R/library'
> 
> The R team itself selected that value for R_LIBS_USER.  Its that way
> in the R source.  If I were picking, I'd probably leave off the
> version number from the end.
> 
> I believe it is recommended to use R_LIBS_SITE. That way, they don't
> block non root users from getting packages "automatically" installed
> in their home dirs.

I decided shortly after our last conversation to just go ahead and make
this change, so as of the last R update, we're now leaving R_LIBS_USER
alone and using R_LIBS_SITE.

For example, my /usr/lib64/R/etc/Renviron (Fedora 14, x86_64) has:

R_LIBS_USER=${R_LIBS_USER-'~/R/x86_64-redhat-linux-gnu-library/2.11'}
#R_LIBS_USER=${R_LIBS_USER-'~/Library/R/2.11/library'}

### Local Variables: ***
### mode: sh ***
### sh-indentation: 2 ***
### End: ***
R_LIBS_SITE=${R_LIBS_SITE-'/usr/local/lib/R/site-library:/usr/local/lib/R/library:/usr/lib64/R/library:/usr/share/R/library'}

> Oh, one more thing. What about "shared" R libraries?
> 
> In the Radmin manual, it claims that R built with shared libraries
> enabled can be 20% slower.  On several Redhat systems here, I've taken
> your RPM and cut the shared option out of configure and I don't notice
> that anything suffers as a result. I don't have any  evidence it is
> faster,either.

I doubt that is valid on Linux, where shared library performance is
almost always on par with static, not to mention the potential benefit
of providing a consistent libRmath library for all packages to use.

I would be willing to reconsider this approach if there were tangible
(and not apocryphal) evidence to show a significant performance gap.

Thanks for the reminder,

~tom