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 <pauljoh...@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@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
