R-java and R-java-devel

[Tom Callaway]

Pierre asked me on irc this afternoon to help him get R-rJava building,
and when I looked at it, I discovered what was wrong.

The Fedora R-core package (the minimum bits needed to get R working)
does not require java. This is intentional, as java is not needed to use
R, and it would be a notable increase in default footprint if we made it
a strict dependency. In the %post for R-core, we run R CMD javareconf,
but that only does something useful if you have a java environment present.

When Pierre was trying to build rJava, R-devel and R-core were being
installed before java-devel and java, thus, the R CMD javareconf run was
happening with no java environment present in the buildroot.

Initially, I tried to resolve this by having the R-rJava package run R
CMD javareconf again during %prep, but this doesn't work, because the
package isn't built as root, and R couldn't update the system configs.
So, as a workaround, I added two new "subpackages" to the main R package:

R-java : A metapackage with no files that simply Requires(post): R-core,
java
R-java-devel: A metapackage with no files that simple Requires(post):
R-devel, java-devel

Both metapackages call R CMD javareconf in their %post (its the same
invocation that we use for R-core). There is some redundancy (it gets
called when we install R-core, then again when we install R-java, for
example), but it isn't harmful.

By then changing the BuildRequires in the R-rJava package from R-devel
to R-java-devel, I was able to get that package to build properly.

There are several advantages to these metapackages:

1. Users who want an R install that comes with the Fedora OpenJDK
preconfigured can yum install R-java.
2. Developers who want an R development environment that has the Fedora
OpenJDK preconfigured can yum install R-java-devel.
3. It does not change the default behavior of the R-core, R-devel (and
R) packages.
4. Any addon R modules that require java to be present and configured
can now use BuildRequires: R-java-devel and be built for Fedora in koji.

If you have any questions about this change, please feel free to ask! :)

Thanks,

~spot

[Pierre-Yves Chibon]

On Mon, 2009-03-23 at 22:04 -0400, Tom "spot" Callaway wrote:

>  There are several advantages to these metapackages:
>  
>  1. Users who want an R install that comes with the Fedora OpenJDK
>  preconfigured can yum install R-java.
>  2. Developers who want an R development environment that has the Fedora
>  OpenJDK preconfigured can yum install R-java-devel.
>  3. It does not change the default behavior of the R-core, R-devel (and
>  R) packages.
>  4. Any addon R modules that require java to be present and configured
>  can now use BuildRequires: R-java-devel and be built for Fedora in koji.
>  
>  If you have any questions about this change, please feel free to ask! :) 
While we are at this, could we add something in /etc/profile.d/ to set
R_HOME to /usr/lib{64}/R ?

I can also include it in R-rJava to make user's life easier :)

Thanks,
Regards,

Pierre

[Tom Callaway]

On 03/24/2009 05:30 AM, Pierre-Yves wrote:

>  While we are at this, could we add something in /etc/profile.d/ to
> set
>  R_HOME to /usr/lib{64}/R ?
>  
>  I can also include it in R-rJava to make user's life easier :) 
R_HOME should always be determined by asking R (R RHOME), so this isn't
necessary.

~spot

[Martyn Plummer]

On Tue, 2009-03-24 at 08:48 -0400, Tom "spot" Callaway wrote:
>  On 03/24/2009 05:30 AM, Pierre-Yves wrote:
>  
>  > While we are at this, could we add something in /etc/profile.d/ to set
>  > R_HOME to /usr/lib{64}/R ?
>  > 
>  > I can also include it in R-rJava to make user's life easier :)
>  
>  R_HOME should always be determined by asking R (R RHOME), so this isn't
>  necessary.
>  
>  ~spot 
I see that you put this in. But it breaks the testing suite in the
current development version. Can we go back over this decision to see
what the original problem was?

Martyn


-----------------------------------------------------------------------
This message and its attachments are strictly confidential. If you are
not the intended recipient of this message, please immediately notify 
the sender and delete it. Since its integrity cannot be guaranteed, 
its content cannot involve the sender's responsibility. Any misuse, 
any disclosure or publication of its content, either whole or partial, 
is prohibited, exception made of formally approved use
-----------------------------------------------------------------------

[Tom Callaway]

On 04/03/2009 03:31 AM, Martyn Plummer wrote:
>  On Tue, 2009-03-24 at 08:48 -0400, Tom "spot" Callaway
> wrote:
> > On 03/24/2009 05:30 AM, Pierre-Yves wrote:
> >
> >> While we are at this, could we add something in /etc/profile.d/ to set
> >> R_HOME to /usr/lib{64}/R ?
> >>
> >> I can also include it in R-rJava to make user's life easier :)
> > R_HOME should always be determined by asking R (R RHOME), so this isn't
> > necessary.
> >
> > ~spot
>  
>  I see that you put this in. But it breaks the testing suite in the
>  current development version. Can we go back over this decision to see
>  what the original problem was? 
Pierre is maintaining an R module (rJava, I think if memory serves),
where it refuses to build/function unless R_HOME is set properly. He
should be able to provide more specifics.

Alternately, might I suggest that the testing suite unset any R related
env variables before running? Seems like a logical catch-all.

~spot

[Martyn Plummer]

On Fri, 2009-04-03 at 09:31 -0400, Tom "spot" Callaway wrote:
>  On 04/03/2009 03:31 AM, Martyn Plummer wrote:
>  > On Tue, 2009-03-24 at 08:48 -0400, Tom "spot" Callaway wrote:
>  >> On 03/24/2009 05:30 AM, Pierre-Yves wrote:
>  >>
>  >>> While we are at this, could we add something in /etc/profile.d/ to set
>  >>> R_HOME to /usr/lib{64}/R ?
>  >>>
>  >>> I can also include it in R-rJava to make user's life easier :)
>  >> R_HOME should always be determined by asking R (R RHOME), so this isn't
>  >> necessary.
>  >>
>  >> ~spot
>  > 
>  > I see that you put this in. But it breaks the testing suite in the
>  > current development version. Can we go back over this decision to see
>  > what the original problem was?
>  
>  Pierre is maintaining an R module (rJava, I think if memory serves),
>  where it refuses to build/function unless R_HOME is set properly. He
>  should be able to provide more specifics. 
Both the CRAN version of the rJava package, and the latest snapshot from
rforge build correctly without having R_HOME set.  This must be
something that happens inside R2spec. I've found Pierre's blog post
where he talks about the problem and will take a look.

M.

[Sorry I keep forgetting that I need to reply to this list using my
r-project.org address. I apologize for the admin messages this
generates]

>  Alternately, might I suggest that the testing suite unset any R
> related
>  env variables before running? Seems like a logical catch-all.
>  
>  ~spot 

-----------------------------------------------------------------------
This message and its attachments are strictly confidential. If you are
not the intended recipient of this message, please immediately notify 
the sender and delete it. Since its integrity cannot be guaranteed, 
its content cannot involve the sender's responsibility. Any misuse, 
any disclosure or publication of its content, either whole or partial, 
is prohibited, exception made of formally approved use
-----------------------------------------------------------------------

[Pierre-Yves Chibon]

On Fri, 2009-04-03 at 19:03 +0200, Martyn Plummer wrote:
>  On Fri, 2009-04-03 at 09:31 -0400, Tom "spot" Callaway
> wrote:
>  > On 04/03/2009 03:31 AM, Martyn Plummer wrote:
>  > > On Tue, 2009-03-24 at 08:48 -0400, Tom "spot" Callaway wrote:
>  > >> On 03/24/2009 05:30 AM, Pierre-Yves wrote:
>  > >>> I can also include it in R-rJava to make user's life easier :)
>  > >> R_HOME should always be determined by asking R (R RHOME), so this
> isn't
>  > >> necessary. 
>  > > I see that you put this in. But it breaks the testing suite
> in the
>  > > current development version. Can we go back over this decision to see
>  > > what the original problem was?
>  > 
>  > Pierre is maintaining an R module (rJava, I think if memory serves),
>  > where it refuses to build/function unless R_HOME is set properly. He
>  > should be able to provide more specifics.
>  
>  Both the CRAN version of the rJava package, and the latest snapshot from
>  rforge build correctly without having R_HOME set.  This must be
>  something that happens inside R2spec. I've found Pierre's blog post
>  where he talks about the problem and will take a look. 
The problem does not come from the build itself.
I managed to build rJava correctly with the change made by spot, the
problem of R_HOME comes when you try to run a R session within Java.
I first met the error I reported in my blog is fixed by moving the file
libjri.so to /usr/lib(64)/, so the RPM now handle it by himself.
But after this problem Java is asking for the R_HOME to be set in the
environment variable (I found the piece of the code that handles this
part, but I don't have it here with me).

Discussing with spot we thought that R_HOME should be set and that it
should be set within the main R package.

I hope that help to understand the problem,

Best regards,

Pierre

[Martyn Plummer]

On Sat, 2009-04-04 at 19:44 +0200, Pierre-Yves wrote:
>  On Fri, 2009-04-03 at 19:03 +0200, Martyn Plummer wrote:
>  > On Fri, 2009-04-03 at 09:31 -0400, Tom "spot" Callaway wrote:
>  > > On 04/03/2009 03:31 AM, Martyn Plummer wrote:
>  > > > On Tue, 2009-03-24 at 08:48 -0400, Tom "spot" Callaway wrote:
>  > > >> On 03/24/2009 05:30 AM, Pierre-Yves wrote:
>  > > >>> I can also include it in R-rJava to make user's life easier
> :)
>  > > >> R_HOME should always be determined by asking R (R RHOME), so this
> isn't
>  > > >> necessary.
>  
>  > > > I see that you put this in. But it breaks the testing suite in the
>  > > > current development version. Can we go back over this decision to see
>  > > > what the original problem was?
>  > > 
>  > > Pierre is maintaining an R module (rJava, I think if memory serves),
>  > > where it refuses to build/function unless R_HOME is set properly. He
>  > > should be able to provide more specifics.
>  > 
>  > Both the CRAN version of the rJava package, and the latest snapshot from
>  > rforge build correctly without having R_HOME set.  This must be
>  > something that happens inside R2spec. I've found Pierre's blog post
>  > where he talks about the problem and will take a look.
>  
>  The problem does not come from the build itself.
>  I managed to build rJava correctly with the change made by spot, the
>  problem of R_HOME comes when you try to run a R session within Java.
>  I first met the error I reported in my blog is fixed by moving the file
>  libjri.so to /usr/lib(64)/, so the RPM now handle it by himself.
>  But after this problem Java is asking for the R_HOME to be set in the
>  environment variable (I found the piece of the code that handles this
>  part, but I don't have it here with me).
>  
>  Discussing with spot we thought that R_HOME should be set and that it
>  should be set within the main R package. 
This is using the JRI interface to call the R engine from within java.
If you want to do this then you should write a wrapper script that sets
all the necessary environment variables, the class path and so on.

The rJava package contains two examples "rtest" and "rtest2", both of
which are installed, along with a wrapper script called "run". These
work perfectly for me:

[martyn@seurat ~]$ cd /usr/lib64/R/library/rJava/jri/
[martyn@seurat jri]$ ./run rtest
...
[martyn@seurat jri]$./run rtest2
...

A more extensive example is the JGR package which provides a Java GUI
for R. The GUI can be launched from the shell by running a wrapper
script - again called "run" - which is installed with the JGR package.
This script also works perfectly for me. 

This is not a reason to set R_HOME globally,

Martyn

>  I hope that help to understand the problem,
>  
>  Best regards,
>  
>  Pierre 

-----------------------------------------------------------------------
This message and its attachments are strictly confidential. If you are
not the intended recipient of this message, please immediately notify 
the sender and delete it. Since its integrity cannot be guaranteed, 
its content cannot involve the sender's responsibility. Any misuse, 
any disclosure or publication of its content, either whole or partial, 
is prohibited, exception made of formally approved use
-----------------------------------------------------------------------

[Tom Callaway]

On 04/06/2009 10:09 AM, Martyn Plummer wrote:
> > Discussing with spot we thought that R_HOME should be set and
> that it
> > > should be set within the main R package.
>  
>  This is using the JRI interface to call the R engine from within java.
>  If you want to do this then you should write a wrapper script that sets
>  all the necessary environment variables, the class path and so on.
>  
>  The rJava package contains two examples "rtest" and "rtest2", both
> of
>  which are installed, along with a wrapper script called "run". These
>  work perfectly for me: 
So... where does it fail? I only added the R_HOME exports on the grounds
that there was a legitimate need for them. If there is not, I'm willing
to drop them. (I didn't want R-rJava to carry the shell scripts, because
I thought that if one R module needed them, another would inevitably
need them as well, then we'd have odd dependency chains on R-rJava.)

Of course, I still stand behind my point that R should unset all the
environment variables that could cause it trouble before running its tests.

~spot

[Pierre-Yves Chibon]

On Mon, 2009-04-06 at 16:09 +0200, Martyn Plummer wrote:
>  This is using the JRI interface to call the R engine from within
> java.
>  If you want to do this then you should write a wrapper script that sets
>  all the necessary environment variables, the class path and so on.
>  
>  The rJava package contains two examples "rtest" and "rtest2", both
> of
>  which are installed, along with a wrapper script called "run". 
Yes and
their first step is:

>  #!/bin/sh
>  
>  R_HOME=/usr/lib64/R 
even before running anything

>  A more extensive example is the JGR package which provides a Java
> GUI
>  for R. The GUI can be launched from the shell by running a wrapper
>  script - again called "run" - which is installed with the JGR package.
>  This script also works perfectly for me. 
>  
>  This is not a reason to set R_HOME globally, 
I see two points, either we help the user by setting the R_HOME ourself
directly within R and rjava works directly or we do not and let set
R_HOME which he will do anyway to make rjava working...

Is there not a way for the testing suite of the development version to
test if R_HOME is already set ?

Another solution could be to add the R_HOME only on the rjava package.

If nothing is acceptable then we should roll back, I don't want to break
R :)

Best regards,

Pierre