On Mon, 03-07-2017, at 07:58:41, Dirk Eddelbuettel <e...@debian.org> wrote: > On 2 July 2017 at 23:24, Kirill Müller wrote: > | On 02.07.2017 22:01, Dirk Eddelbuettel wrote: > | > On 2 July 2017 at 21:39, Kirill Müller wrote: > | > | Hi > | > | > | > | An upgrade to R 3.4.1 on Ubuntu removed the default setting of > | > | R_LIBS_USER in /etc/R/Renviron. What's the rationale behind this? > Thanks. > | > > | > Pretty much exactly what I told you in person last week :) > | > > | > - idea is to prefer /usr/local/lib/R/site-library/ > | > - multi-user more important than per-user > | > > | > Also see https://bugs.debian.org/866768 > | > > | > The transition may be too harsh though. I did not consider the > possibility of > | > /usr/local/lib/R/site-library/ *not* being writeable. So what I could do > is > | > to re-add the per-user directory as a fall-back after the preferred > | > /usr/local/lib/R/site-library. > | Thanks. The site-library is owned by root/staff on my system, and my > | user isn't member of the staff group (Ubuntu 17.04). I'm not sure how > | this looks on a factory-fresh install, but IMO users should be able to > | just use install.packages(). > > You should (as the local admin) set up appropriate groups and policies. > > In the simplest case, one addgroup would do. > > Worst case you can also > > i) wrap sudo around the installation step, > ii) make the directory world-writeable or > iii) set R_LIBS_USER in the *.site files. > > I still feel (quite strongly) that this policy is the best, I do also see > that the implementation may not be ideal -- not running install.packages() > well is a bit of a, err, "setback". Maybe I need to add it again at the end > of .libPath() ?
If I might chime in, I'd like to add my vote to the "users should be able to use install.packages and should be able to install bioconductor packages with biocLite". Longer story ============ Two cases (I've just faced this morning), where /usr/local/lib/R/site-library/ was not user-writeable: 1. Students using Debian or Ubuntu on their laptops, where these students are not particularly knowledgeable about Linux. 2. Sys admins that install and configure software for computer labs, where beyond some bare minima (e.g., R, gcc, etc) users are expected and allowed to install (some) software on their homes. These sys admins might be specially reluctant to add users to privileged groups and/or make /usr/local/lib/R/site-library user-writeable. The problem is that both groups, after issuing the sudo apt-get install r-base sudo apt-get install r-base-dev (as per https://cran.r-project.org/bin/linux/ubuntu/README.html) are later surprised when users cannot immediately install packages in the "usual R way (install.packages)". And this gets more complicated when we add a bunch of bioconductor packages, where BioConductor pages often say to install as source("https://bioconductor.org/biocLite.R";) biocLite(some_packages) I've ended up doing .libPaths(c(the_user_home, .libPaths())) but this does not look very friendly for new users. Best, R. > > Dirk > > | > | > | -Kirill > | > | > Dirk > | > > | -- Ramon Diaz-Uriarte Department of Biochemistry, Lab B-25 Facultad de Medicina Universidad Autónoma de Madrid Arzobispo Morcillo, 4 28029 Madrid Spain Phone: +34-91-497-2412 Email: rdia...@gmail.com ramon.d...@iib.uam.es http://ligarto.org/rdiaz _______________________________________________ R-SIG-Debian mailing list R-SIG-Debian@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-debian
