Two R editiosn in Unix cluster systems
OpenMx does install on R 3.01. I haven't tested extensively, but after
installing with
install.packages('OpenMx',
dependencies = TRUE,
repos = c(getOption("repos"),
'http://openmx.psyc.virginia.edu/sequential/'))
the demos appear to run correctly.
Best,
Ista
On Tue, Oct 15, 2013 at 4:15 PM, Paul Johnson <pauljohn32 at gmail.com> wrote:
Dear R Devel Some of our R users are still insisting we run R-2.15.3 because of difficulties with a package called OpenMX. It can't cooperate with new R, oh well. Other users need to run R-3.0.1. I'm looking for the most direct route to install both, and allow users to choose at runtime. In the cluster, things run faster if I install RPMs to each node, rather than putting R itself on the NFS share (but I could do that if you think it's really better....) In the past, I've used the SRPM packaging from EPEL repository to make a few little path changes and build R RPM for our cluster nodes. Now I face the problem of building 2 RPMS, one for R-2.15.3 and one for R-newest, and somehow keeping them separate. If you were me, how would you approach this? Here's my guess First, The RPM packages need unique names, of course. Second, leave the RPM packaging for R-newest exactly the same as it always was. R is in the path, the R script and references among all the bits will be fine, no need to fight. It will find what it needs in /usr/lib64/R or whatnot. For the legacy R, I'm considering 2 ideas. I could install R with the same prefix, /usr, but very careful so the R bits are installed into separate places. I just made a fresh build of R and on RedHat 6, it appears to me R installs these directories: bin libdir share. So what if the configure line has the magic bindir=/usr/bin-R-2.15.3 libdir = /usr/lib64/R-2.15.3, and whatnot. If I were doing Debian packaging, I suppose I'd be obligated (by the file system standard) to do that kind of thing. But it looks like a headache. The easy road is to set the prefix at some out of the way place, like /opt/R-2.15.3, and then use a post-install script to link /opt/R-2/15.3/bin/R to /usr/bin/R-2.15.3. When I tried that, it surprised me because R did not complain about lack access to devel headers. It configures and builds fine. R is now configured for x86_64-unknown-linux-gnu Source directory: . Installation directory: /tmp/R C compiler: gcc -std=gnu99 -g -O2 Fortran 77 compiler: gfortran -g -O2 C++ compiler: g++ -g -O2 Fortran 90/95 compiler: gfortran -g -O2 Obj-C compiler: gcc -g -O2 -fobjc-exceptions Interfaces supported: X11, tcltk External libraries: readline, ICU, lzma Additional capabilities: PNG, JPEG, TIFF, NLS, cairo Options enabled: shared BLAS, R profiling, Java Recommended packages: yes Should I worry about any runtime complications of this older R finding its of the newer R in the PATH ahead of it? I worry I'm making lazy assumptions? After that, I need to do some dancing with the RPM packaging. I suppose there'd be some comfort if I could get the users to define R_HOME in their user environment before launching jobs, I think that would eliminate the danger of confusion between versions, wouldn't it? pj -- Paul E. Johnson Professor, Political Science Assoc. Director 1541 Lilac Lane, Room 504 Center for Research Methods University of Kansas University of Kansas http://pj.freefaculty.org http://quant.ku.edu [[alternative HTML version deleted]]
______________________________________________ R-devel at r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel