Skip to content

update.packages(1)

4 messages · Arni Magnusson, Seth Falcon, Duncan Murdoch

Original
Arni Magnusson
# 
I'm relaying a question from my institute's sysadmin:

Would it be possible to modify update.packages() and related functions so 
that 'lib.loc' accepts integer values to specify a library from the 
.libPaths() vector?

Many Linux users want to update all user packages (inside the R_LIBS_USER 
directory, e.g. ~/r/library) and none of the system packages (inside the 
/usr directory, e.g. /usr/lib64/R/library), because they don't have write 
privileges to update the system packages.

Currently, this can be done by pressing 'y RET' for all the user packages 
and 'RET' for all the system packages. This hard work and careful reading 
when there dozens of packages. Another way is to run

   update.packages(Sys.getenv("R_LIBS_USER"))

or:

   update.packages(.libPaths()[1])

But it would be nicer for the user to type

   update.packages(1)

using a 'pos' like notation to indicate the first element of the 
.libPaths() vector.

---

A separate but related issue is that it would be nice if the R_LIBS_USER 
library would be the first library by default. Currently, my sysadmin must 
use Rprofile.site to shuffle the .libPaths() to make R_LIBS_USER first, 
which seems like a sensible default when it comes to install.packages() 
and remove.packages().

This is R version 2.10.1 (2009-12-14) on x86_64-redhat-linux-gnu (Fedora 
11).

Thanks,

Arni
2 days later
Duncan Murdoch
#
On 25/03/2010 3:16 PM, Arni Magnusson wrote:
You could also save some work by putting ask=FALSE, or ask="graphics" in 
as another argument.  But isn't it easy enough to write your own 
function as a wrapper to update.packages, suiting your own local 
conventions?   It seems like a bad idea to make update.packages too 
friendly, when there are several different friendly front-ends for it 
already (e.g. the menu entries in Windows or MacOS GUIs).
I didn't write it, but I suspect the current behaviour was intentional. 
  Without it, it would be hard to put the user library last, since 
.libPaths() adds things at the front.  Now you have a choice:  use the 
R_LIBS_USER environment variable to put it last, use a line in your 
Rprofile.site file to put something first.

Duncan Murdoch
Seth Falcon
#
On 3/27/10 1:43 PM, Duncan Murdoch wrote:
I'm confused.  AFAICT, R_LIBS_USER _is_ put first.  Following the advice
in the Admin manual, I created a directory matching the default value of
R_LIBS_USER (Sys.getenv("R_LIBS_USER") to see it).  Then when I start R,
I get:
[1] "/home/sfalcon/R/x86_64-unknown-linux-gnu-library/2.11"
[2] "/home/sfalcon/build/rd/library"

Isn't that what you want?
Duncan Murdoch
#
On 27/03/2010 4:48 PM, Seth Falcon wrote:
I didn't try it, I just read the documentation (in ?.libPaths).  As I 
read it it says the order is

R_LIBS, R_LIBS_USER, .Library.site, .Library

and some of those components can be missing.

So another way to put the user libs first is to specify the site libs in 
.Library.site rather than in the environment variable.

Duncan Murdoch