R 2.12.0 in Fedora Updates Testing
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