37

When installing R packages (say mcmcpack in this example) under Ubuntu I have the choice between the following two methods of installation:

# Let the distribution's packaging system take care of installation/upgrades
apt-get install r-cran-mcmcpack

# Let R take care of installation/upgrades
install.packages("mcmcpack")

Questions:

  • Is any of the two ways of installing R packages considered "best practice"?
  • Assume that I first install.packages("mcmcpack") and later on apt-get install r-cran-mcmcpack - should I expect trouble?
  • Assume that I first apt-get install r-cran-mcmcpack and later on install.packages("mcmcpack") - should I expect trouble?
knorv
  • 49,059
  • 74
  • 210
  • 294

2 Answers2

38

Update (some thirteens years later): It is now as easy as it seems if you use for example the wonderful and powerful r2u system I set up last year, and which now provides over 20k binary .deb packages for each of twi Ubuntu LTS releases (currently: 20.04 and 22.04), and is also accessible via install.packages() thanks top bspm. Follow the link to r2u for more.

It's not as easy as it seems.

  • apt-get update is good if and when

    • packages exist -- but there are only around 150 or so r-cran-* packages out of a pool of 2100+ packages on CRAN, so rather sparse coverage

    • packages are maintained, bug free and current

    • you are happy enough with the bi-annual releases by Ubuntu

  • install.packages() and later update.packages() is good if and when

    • you know what it takes to have built-time dependencies (besides r-base-dev) installed

    • you don't mind running update.packages() by hand as well as the apt-get updates.

On my Ubuntu machine at work, I go with the second solution. But because the first one is better if you have enough coverage, we have built cran2deb which provides 2050+ binary deb packages for amd64 and i386 --- but only for Debian testing. That is what I use at home.

As for last question of whether you 'should you expect trouble': No, because R_LIBS_SITE is set in /etc/R/Renvironment to be

# 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'}

which means that your packages go into /usr/local/lib/R/site-library whereas those managed by apt go into /usr/lib/R/site-library and (in the case of base packages) /usr/lib/R/library.

Hope that clarifies matters. The r-sig-debian mailing list is a more informed place for questions like this.

Dirk Eddelbuettel
  • 360,940
  • 56
  • 644
  • 725
  • Dirk, I hate to make this a stand alone question... Why are some packages (e.g. RODBC) only able to be installed using the apt-get install method? – JD Long Feb 01 '10 at 19:00
  • Where? How? When? What platform? Feel free to email r-sig-debian, that;s what we have it for (SO fanboy-ism notwithstanding). – Dirk Eddelbuettel Feb 01 '10 at 19:21
  • Did you 'simply' miss the odbc development package etc? Well, that would be _why_ we started to provide these. RODBC was actually one of the first I packaged... – Dirk Eddelbuettel Feb 01 '10 at 19:21
  • See also https://cran.rstudio.com/bin/linux/ubuntu/README.html for repositories to install recent R and R packages. – gerlos May 18 '16 at 08:44
5

  • I'd consider using apt-get best practice since you will get automatic updates through the standard system tools.

  • Having 2 versions installed might get you into confusing situations: depending on your R setup you could load another package version then you expect -- your private (maybe outdated) one should in general be loaded first.

  • See above.

Benjamin Bannier
  • 55,163
  • 11
  • 60
  • 80