R-2.9.0
by Pierre-Yves Chibon
Hi all,
Spot next time could you advertise here a bit more before pushing a new
R release into stable ? :)
(It would have avoid me #497320)
It's not a big deal not having it would have been nicer for the users :)
Thanks,
Best regards,
Pierre
14 years, 7 months
Re: [Fedora-r-devel-list] R-java and R-java-devel
by Martyn Plummer
On Tue, 2009-04-07 at 12:59 +0200, Pierre-Yves wrote:
> On Tue, 2009-04-07 at 12:09 +0200, Martyn Plummer wrote:
>
> > Setting R_HOME in the environment before launching R is the wrong
> > thing to do.
> Just out of curiosity, why ? R_HOME should be coherent between the
> environment and R itself, through a warning if they are different makes
> sense (IMHO), but if they are the same what is the problem ?
People can and do have multiple R installations. Most of these people
are developers, but we also encourage users to download and test beta
releases. You are currently breaking developer builds by setting R_HOME
to point to the Fedora RPM. Of course, the breakage is relatively
minor, and takes the form of annoying warnings, but those warnings were
put there for a reason.
The user is not meant to set R_HOME. The system administrator is
certainly not meant to set R_HOME. R_HOME is meant to be set by the
application that starts the R engine, and it does so in its own shell so
that there are no side effects. This allows multiple versions of R to
coexist on the same system.
The only reason that the warning is silenced when the R_HOME environment
variable matches the correct value is because the R script can
recursively call itself, e.g.
R CMD Sweave foo.Rnw
will call two instances of the R shell script, and in the second call
R_HOME is already set by the first call.
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
-----------------------------------------------------------------------
14 years, 8 months
Re: [Fedora-r-devel-list] R-java and R-java-devel
by Martyn Plummer
On Mon, 2009-04-06 at 17:26 +0200, Pierre-Yves wrote:
> 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...
How does it help the user to set R_HOME?
The rJava package does two things:
1) It allows the R user to call java functions from within R.
2) It allows applications written in java to start an instance of the R
engine and pass data and commands back and forth.
It is the second use (the JRI interface) that concerns us. There are
three parties in this situation:
1) R
2) The user
3) A third party java application.
The responsibility for setting R_HOME lies firmly with the third-party
application, which should launch from within its own shell, within which
R_HOME is set to the appropriate value. This value should be determined
when the application is configured. The user should never have to set
it.
> Is there not a way for the testing suite of the development version to
> test if R_HOME is already set ?
Setting R_HOME in the environment before launching R is the wrong
thing to do. That is why the R shell script prints a warning, and it is
the presence of this warning that is causing the test suite to fail.
> 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
-----------------------------------------------------------------------
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
-----------------------------------------------------------------------
14 years, 8 months
R-java and R-java-devel
by 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
14 years, 8 months
License
by Pierre-Yves Chibon
Dear all,
I am having a small question/problem for the review [1].
Upstream updated the sources [2]-[3] which now mention in the
description file:
--------------------------
License: Artistic-2.0
ExtraLicenses: The following files in the 'src' directory are licensed
for all
use by Jim Kent, in a manner compatible with the Artistic 2.0 license:
common.c/h, memalloc.c/h, localmem.c/h, hash.c/h, errabort.c/h,
rbTree.c/h,
dlist.c/h, errCatch.h
----------------------------
How should I mention that in the spec file ?
Should I keep Artistic 2.0 ?
Thanks for your help,
Best regards,
Pierre
[1] https://bugzilla.redhat.com/show_bug.cgi?id=490723
[2] http://bioconductor.org/packages/2.4/bioc/html/IRanges.html
[3]
http://bioconductor.org/packages/2.4/bioc/src/contrib/IRanges_1.1.55.tar.gz
14 years, 8 months
