r-devel April 2009

r-devel@lists.fedoraproject.org

3 participants
6 discussions

Update the guidelines
by Pierre-Yves Chibon 04 Aug '09

04 Aug '09

Dear all, I would like to propose to update (or mention) some points in the R packaging guidelines. * Mention something about the tex files which are not utf-8 and don't necessarily have to be converted see: https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00741.html * Mention something about the -devel package where the headers don't necessarily have to moved to %{_datadir} since R looks for them in %{_libdir}. see: https://www.redhat.com/archives/fedora-r-devel-list/2009-March/msg00001.html What is your opinion on these changes ? What is the process to propose such changes/updates ? Thanks, Best regards, Pierre

1 2

R-2.9.0
by Pierre-Yves Chibon 23 Apr '09

23 Apr '09

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

2 1

Re: [Fedora-r-devel-list] R-java and R-java-devel
by Martyn Plummer 08 Apr '09

08 Apr '09

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 -----------------------------------------------------------------------

3 3

Re: [Fedora-r-devel-list] R-java and R-java-devel
by Martyn Plummer 07 Apr '09

07 Apr '09

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 -----------------------------------------------------------------------

2 1

R-java and R-java-devel
by Tom Callaway 06 Apr '09

06 Apr '09

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

3 9

License
by Pierre-Yves Chibon 01 Apr '09

01 Apr '09

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

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

r-devel April 2009