Re: [Fedora-r-devel-list] [R-sig-Fedora] Improving RPM packaging for R; ideas gathered from the Debian folks
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
"Tom "spot" Callaway" tcallawa-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org writes:
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. :)
I have deep sympathy with this perspective.
There's a corrolary of it, though, that sticks in my craw, and is the primary reason I'm trying to advance the autogenerated case. I'll attempt to state it briefly. (hah.)
" No CRAN package shall be available to distro X, except that some distro maintainer first
1) become aware of it 2) care about it 3) have the time to a) build it b) understand it "
I think this is your goal, right?
We have essentially an alpha-error / beta-error problem here, on the statement H0: "this package can be built cleanly".
On the autogen side, we plan for beta error: we build some packages that fail.
On the constant-gardener side, we plan for alpha error: we fail to build some packages which we would predict will work.
I think that the bulk of packages will autogenerate smoothly and work. Because of this, I make the aesthetic call that we help more people by generating them all, and then gradually nibbling at the problem packages.
I'm emphasizing the subjective nature of these calls to make it clear that I'm not trying to say "I'm right", but instead the much weaker "This is how it looks to me".
- Allen S. Rout
r-devel@lists.fedoraproject.org
-
Allen S. Rout -
Tom Callaway