Hi, Thanks for the clarification. As long as the admins don't mind (which I guess they won't because it means they won't have to build RPMs or binaries), I will be okay with just using local versions of the libraries. I just wanted to make sure I wasn't missing something obvious (which is probably pretty likely in situations like this). Thanks again for your help.
-Rhiannon On Tue, 6 Feb 2007, Prof Brian Ripley wrote: > 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@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel >> > > -- > Brian D. Ripley, [EMAIL PROTECTED] > 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 > ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel