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
On Mon, 2009-03-23 at 22:04 -0400, Tom "spot" Callaway wrote:
There are several advantages to these metapackages:
- 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
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
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 -----------------------------------------------------------------------
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
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 -----------------------------------------------------------------------
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
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 -----------------------------------------------------------------------
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
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
r-devel@lists.fedoraproject.org
-
Martyn Plummer -
Pierre-Yves Chibon -
Tom Callaway