r-devel March 2009

r-devel@lists.fedoraproject.org

4 participants
5 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-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

R RPM requirements
by Martyn Plummer 27 Mar '09

27 Mar '09

One of the topics that came up during the thread "R-devel going away" was that R-devel has a rather heavy set of requirements. Some of these looked implausible to me, even though I am probably responsible for putting them in in the first place. This prompted me to go back to basics and work out what the requirements of R-core and R-devel should really be. I wrote a document in December, but never circulated them for some reason. You can find it here (PDF document and LaTeX source): http://calvin.iarc.fr/~martyn/software/R It may look like heavy going, but you can skip to the conclusions if you get bored. The bottom line is that a lot of the current requirements of R-devel can be dropped, but there are also a few other requirements that should, in principle, be added. If you do find it useful, it could go in a wiki so that it can be kept up to date. 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 -----------------------------------------------------------------------

1 0

Update R2spec
by Pierre-Yves Chibon 23 Mar '09

23 Mar '09

Dear all, A new version of R2spec is pending for updates-testing. It comes some time after the previous version and some things have been added or corrected in it. There is the changelog concerning this release: Version 2.5.2 -- 21st Mar 2009 -Features added * Do not ask to move the file if there is no %_topdir * Add option -c/--copyFile to copy the source to %_topdir without asking * Add the option -n/--name to specify the name of the packager * Add the option -e/--email to specify the email of the packager * Add the option -f/--force that create the spec file with the normal name even if there is already such a file in the working directory * Add zip support * Remove the '(', ')' and the ',' in the BuildRequire and Require of the spec * Check if the source actually exists (it was about time...) * Better handling of the exception * Change %define to %global in the generated spec according to the new guidelines -Bugs correction * Typo -> 'Copy to' and not 'copy in' * Change the comment on the spec for x86/x86_64 and noarch * Actually copy the source file to the SOURCES folder * The Source0 is not a template anymore it is either from -s or it is -u Please let me know if you find any bug or have any wishes that you would like to see in R2spec. Best regards, Pierre

2 1

-devel packages
by Pierre-Yves Chibon 16 Mar '09

16 Mar '09

Dear list, Once again I come here to ask for your help/opinion :-) I have decided to give some more love to two of my packages: R-BSgenome.Dmelanogaster.FlyBase.r51 and R-BSgenome.Celegans.UCSC.ce2 In order to be able to build the latest versions of them I need to package the following: R-IRange R-Biostrings and R-BSgenome So I did and before submitting them for review, I would like to expose here the problem I have with them. While packaging R-IRange has obtain: R-IRanges.x86_64: W: devel-file-in-non-devel-package /usr/lib64/R/library/IRanges/include/... So I divided the package in a sub package -devel with the following error: R-IRanges-devel.x86_64: E: only-non-binary-in-usr-lib while all the package is in %{_libdir} If I move the headers from %{_libdir} to %{_datadir} as rpmlint ask then I have to do the following in R-Biostrings spec: ---------------SPEC # Replace the wrong include by the rights one :) for i in %{packname}/src/*.c do sed -i -e 's|#include "IRanges_interface.h"| #include "%{_datadir}/R/library/IRanges/include/include/IRanges_interface.h"|' $i done sed -i -e 's|#include "IRanges_defines.h"| #include "%{_datadir}/R/library/IRanges/include/include/IRanges_defines.h"|' %{packname}/inst/include/Biostrings_de fines.h sed -i -e 's|#include "_IRanges_stubs.c"| #include "%{_datadir}/R/library/IRanges/include/include/_IRanges_stubs.c"|' %{packname}/src/IRanges_stubs.c -----------------EOF Because else Biostrings cannot find the correct headers and thus cannot compile... And... R-Biostrings needs also to be split in a subpackage -devel with the headers in %{_libdir} while the package is installed in %{_datadir} so R-BSgenome will also have to be "patched" for the headers. Is there a way to make R looking in both %{_datadir} and %{_libdir} while it looks for the headers ? Could I leave the R headers in %{_libdir} ? (I guess not but worth to ask ^^) Any suggestion/remarks ? Thanks in advance, Best regards, Pierre

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

r-devel March 2009