r-devel February 2010

r-devel@lists.fedoraproject.org

2 participants
3 discussions

R-multcomp and a lot of new R packages
by Tom Callaway 06 Jul '10

06 Jul '10

The R-multcomp maintainer asked me to look into why it was failing to build in rawhide. When I looked into it, I discovered that something is broken in how R CMD CHECK --no-install works in 2.10.1. I couldn't tell you what is broken exactly, but I took the time today to package up all the Suggests (and their depchain) and tested the package without --no-install (and without --no-latex) and it works fine again. I asked Orion (the R-multcomp maintainer) if he was interested in maintaining/co-maintaining/reviewing these new R packages, but he wasn't interested. In fact, he said he was more inclined to orphan R-multcomp. Is there any interest in helping me maintain and review these new R packages in Fedora? The packages are already done, its just the reviews and upkeep that I'd need help with. Here's the packages: http://auroralinux.org/people/spot/review/R-multcomp/ These are the R packages I made today: coin, colorspace, ipred, lme4, mboost, mlbench, modeltools, multicore, party, robustbase, sandwich, strucchange, vcd, xtable If any of these look interesting to you, speak up! If no one cares, I might just let R-multcomp orphan off, but if there are some willing helpers, I'll keep it alive with its new dependencies. ~spot

3 3

Re: [Fedora-r-devel-list] [R-sig-Fedora] Improving RPM packaging for R; ideas gathered from the Debian folks
by Tom Callaway 15 Feb '10

15 Feb '10

On 02/03/2010 09:12 PM, Paul Johnson wrote: > One of the really handy R packaging ideas they have > is to customize R environment so that there are several directories in > the package path. > > It adjusts the etc/Renviron file so that it has: > > R_LIBS_USER=${R_LIBS_USER-'~/R/i486-pc-linux-gnu-library/2.10'} > R_LIBS_SITE=${R_LIBS_SITE-'/usr/local/lib/R/site-library:/usr/lib/R/site-library:/usr/lib/R/library'} > > That would be pretty easy to add into the R packaging for RPM systems. > > The benefit is as follows. > > If an unprivileged user tries to install an R package, there's no > error, but rather it installs the rpm under $HOME/R/i386. Well, I don't think a standard setup will permit an unprivileged user to install rpm packages, but this should work when building things from CRAN, I suppose. My only concerns are: 1) Users shouldn't be assuming that /usr/local/lib/R exists. Fedora packages can't create that directory, and we don't really want the first user to hit that directory to create it with their own ownership privs. 2) Right now, we have two locations for R packages from Fedora: %{_libdir}/R/library/* and %{_datadir}/R/library/* (arch vs noarch). I'm not sure it is worth making another set of separate directories. Or to sum it up, I think the R_LIBS_USER setting makes some sense, but I'm not sure the additional complexity of R_LIBS_SITE adds any value. Also, I'm not sure why there is so much hierarchy in the proposed setting for R_LIBS_USER. The R version, perhaps is understandable, but the target architecture? > "Over there" in r-sig-deb, I learned that Dirk Eddelbuettel and > Charles Blundell developed a thing called "cran2deb". > > http://www.mail-archive.com/debian-science@lists.debian.org/msg03306.html > > That has debian packages of almost every R package you can get on CRAN. I'm not personally a fan of autogenerated packages. If people are interested in a CRAN package, we can get it added to Fedora and properly maintained. The number of times that RScaLAPACK has broken has convinced me of the value of having someone responsible for keeping these bits alive. :) With that said, various folks have made some good tools for making quick and easy R module RPM packages, and those are an excellent first step for getting those packages into Fedora. ~spot

2 1

Re: [Fedora-r-devel-list] [R-sig-Fedora] Improving RPM packaging for R; ideas gathered from the Debian folks
by Tom Callaway 08 Feb '10

08 Feb '10

On 02/08/2010 04:07 PM, Peter Dalgaard wrote: > Think networked drives. Is the users home dir mounted on Linux, Solaris, > Mac, or maybe a P: drive on Windows? Well, having also been there, I think that sort of environment involves customization beyond that provided by the distribution. Or, to put it succinctly, we should not target madness by default. :) ~spot

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

r-devel February 2010