Hello, Tech question, I hope this has not been addressed before. I searched help archives and looked for online help but came up empty-handed. My question is: (short version) Is there a RPM-supported version of update.packages() for use with updating package libraries on managed multi-user Linux networks? Details: I put in a request for updating the version of R on one of the hosts on my work Unix network, which is managed by our IT department. Current version is 2.1.0; I asked them to update to 2.4.1. The core update installed and I was able to test it, but the update had trouble loading the package "Matrix" for use with "lme4". I don't recall the specific error (will check it out when the new version gets re-installed again and I can document it). Other packages (lme, wavethresh, MASS) seemed to load without problems. I think the Matrix problem can be solved by running update.packages() but when I requested the admin to update packages for the new version, they said that they need to do this via an RPM. Specifically (and I'm not a network guru so my advice may not be entirely accurate): me: I think if you have admin access you should be able to update the R packages by using the command update.packages() from within a running, updated version of R, and it will automatically check packages for new versions and update them. admin: But this method moves us to an unsustainable host with locally installed packages. The add-on packages need to be installed via an RPM. As I understand it, RPM is like a kind of makefile for Linux machines. The help mentions need of -devel or -dev files for RPM installations and updates of the core software; is there a similar avenue I can point my admin to for package updates? I'm not afraid of a little Linux, but I fear I am a bit out of my element on this one. Currently the workaround is for them to install the new version and for me to download and maintain packages locally. Thanks very much for your time, -Rhiannon
The problem is the speed with which R packages change. My dept considered this, and decided against. There have been something like 200 new versions of CRAN packages already this year. Even if we provided automated wrappers to make source RPMs, someone would still have to build the binary RPMs for your (unstated) architecture and then install it. Unless you use very few packages nor sysadmin is going to be happy with this approach. It really is quite easy to have your own library and install packages there, and it will become easier in 2.5.0. Your 'workaround' is the preferred solution for many sites including ours, although for our most popular architectures we also run a central site-library of popular packages (e.g. those used for teaching here). On Tue, 6 Feb 2007, Rhiannon L Weaver wrote:> Hello, > > Tech question, I hope this has not been addressed before. I searched help > archives and looked for online help but came up empty-handed. > > My question is: (short version) Is there a RPM-supported version of > update.packages() for use with updating package libraries on managed > multi-user Linux networks? > > Details: > > I put in a request for updating the version of R on one of the hosts on my > work Unix network, which is managed by our IT department. Current version > is 2.1.0; I asked them to update to 2.4.1. The core update installed and I > was able to test it, but the update had trouble loading the package > "Matrix" for use with "lme4". I don't recall the specific error (will > check it out when the new version gets re-installed again and I can > document it). Other packages (lme, wavethresh, MASS) seemed to load > without problems. > > I think the Matrix problem can be solved by running update.packages() but > when I requested the admin to update packages for the new version, they > said that they need to do this via an RPM. Specifically (and I'm not a > network guru so my advice may not be entirely accurate): > > me: I think if you have admin access you should be able to update the R > packages by using the command update.packages() from within a running, > updated version of R, and it will automatically check packages for new > versions and update them. > > admin: But this method moves us to an unsustainable host with locally > installed packages. The add-on packages need to be installed via an RPM. > > As I understand it, RPM is like a kind of makefile for Linux machines. > The help mentions need of -devel or -dev files for RPM installations and > updates of the core software; is there a similar avenue I can point my > admin to for package updates? I'm not afraid of a little Linux, but I > fear I am a bit out of my element on this one. > > Currently the workaround is for them to install the new version and for me > to download and maintain packages locally. > > Thanks very much for your time, > -Rhiannon > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel >-- Brian D. Ripley, ripley at stats.ox.ac.uk Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UK Fax: +44 1865 272595
>>>>> "Jari" == Jari Oksanen <jarioksa at sun3.oulu.fi> >>>>> on Wed, 07 Feb 2007 16:28:14 +0200 writes:Jari> On Wed, 2007-02-07 at 14:57 +0100, Martin Maechler wrote: >> >>>>> "Rhiannon" == Rhiannon L Weaver <rlweaver at stat.cmu.edu> >> >>>>> on Tue, 6 Feb 2007 14:35:31 -0500 (EST) writes: >> Rhiannon> Hi, >> Rhiannon> Thanks for the clarification. As long as the Rhiannon> admins don't mind (which I guess they won't Rhiannon> because it means they won't have to build RPMs or Rhiannon> binaries), I will be okay with just using local Rhiannon> versions of the libraries. >> >> You will be using local version of the ** packages ** >> by installing them into your own library. Try to be careful not >> to confuse the two terms. Jari> This is what Wikipedia says: Jari> "R is also highly extensible through the use of packages, which are Jari> user-submitted libraries..." Jari> (http://en.wikipedia.org/wiki/R_%28programming_language%29) Jari> Time to correct Wikipedia? Yes, please! I don't have time currently... Martin
I feel your pain. At my workplace, the network administrators insist that anything that is to be distributed across the network be packaged up in an RPM. I have my own library of packages accessible to my section members, but when I want to make something available to everyone, I have to create an RPM. After many trials and tribulations, here is the rpm spec file I created for Prof. Ripley's RODBC package. A few things to note: 1. R-2.4.0 was installed in /opt/r-2.4.0 by an RPM called R-arc 2. I create /opt/r-2.4.0/lib/R/src and unpack the source package there, so my users can look at the original code if they want to. 3. The rpm does R CMD INSTALL pkg twice: once when it is installing the rpm, and again in the post-install step. The reason for the second pass is to insure that the help index files get rebuilt with all of the packages that are installed in the production directory. My other rpms are similar to this one. With that, here is the spec file: -- Jeff %define rversion 2.4.0 %define rtopdir /opt/r-%{rversion} %define rhome %{rtopdir}/lib/R %define rbin %{rhome}/bin/R %define rSourcePackageDir %{rhome}/src %define rBinaryPackageDir %{rhome}/library %define arcrel 9 Name: R-rodbc-arc Version: %{rversion} Release: 1.1.REV.%{arcrel} Summary: Package ODBC Interface for R License: free Requires: R-arc >= %{rversion} Provides: R-rodbc Group: Applications/Engineering Source0: %{name}-%{version}.tar.gz Buildroot: /tmp/%{name}-%{version} %description CRAN version 1.1-7 of RODBC, an ODBC interface for R. %prep %build %install [ "%{buildroot}" != "/" ] && rm -rf %{buildroot} mkdir -p %{buildroot}%{rBinaryPackageDir} mkdir -p %{buildroot}%{rSourcePackageDir} mkdir -p %{buildroot}%{rhome}/doc/html/search cd %{buildroot}%{rSourcePackageDir} tar -xzf $RPM_SOURCE_DIR/%{name}-%{version}.tar.gz %{rbin} CMD INSTALL -c -l %{buildroot}%{rBinaryPackageDir} RODBC %files %defattr(-, mathadm, appgrp) %{rSourcePackageDir}/* %{rBinaryPackageDir}/* %clean rm -rf %{buildroot} %post cd %{rSourcePackageDir} pwd %{rbin} CMD INSTALL -c RODBC chown -R mathadm:appgrp %{rBinaryPackageDir}/RODBC chown mathadm:appgrp %{rhome}/doc/html/packages.html chown mathadm:appgrp %{rhome}/doc/html/search/index.txt %preun