R-2.2.0 was released on October/6th. The attached ebuild is an updated version of the ebuild for R-2.1.0. I added some lines to src_install() to fix the R_SHARE_DIR, R_INCLUDE_DIR and R_DOC_DIR env. variables on the /usr/bin/R script.
Created attachment 70240 [details] ebuild.
*** Bug 112022 has been marked as a duplicate of this bug. ***
hi fernando: could you please add the patched R into it, too? it should be easy (see my duplicate report http://bugs.gentoo.org/show_bug.cgi?id=112022 ), and it fixes some pdf() device bugs. it is also very stable. PS: the revised R ebuild did not show up in my /usr/portage dir yet. regards, /iaw
I'm currently working in this ebuild, using it with the latest patch. Lucas Chiesa
Created attachment 72580 [details, diff] Very small patch to make the ebuild use the latest patch version. I have not yet tested very well, posted just to make it available. Lucas Chiesa
I've tested the patched ebuild here and it's working fine. I think it can be added to the portage tree now.
You should never drop keywords in ebuilds (they are dropped to ~). I will try to take a closer look at this ebuild and get it into portage. There are a few other outstanding bugs, and if possible I would like to ensure they are addressed too in this bump.
The official tarball should be used, and patches applied to that in the ebuild.
(In reply to comment #8) > The official tarball should be used, and patches applied to that in the > ebuild. Yes, "R-patched" source changes *daily*. The ebuild should point to the *stable* released version of R, which is currently 2.2.0. I'm not even sure there *is* a collection of patches against the stable release, but I can certainly check CRAN. And on top of that, the Gentoo R maintainer would need to have a bug in Gentoo Bugzilla for each bug in the R database -- sounds like a full-time job. Heck, even Debian, with a more or less captive R maintainer, Dirk Eddelbuettel, doesn't track all the CRAN patches. If *you* want R-patched, just download it, build it from source and change your path to over-ride the R you get from Portage. Which is what I've had to do while waiting for R-2,2.0 to show up in Portage. :) End of rant!
however, the patches sometimes do include important updates---as they do here for the pdf() driver. let's hope that we get 2.2.1 soon, in this case. of course, gentoo cannot always have all patched versions set up, but sometimes, this is not a bad thing (see, e.g., xv). sincerely, /iaw
Is there a way to make an ebuild that points to R-patched, something like a CVS version we have for some other packages? That way we can have the stable 2.2 version and the patched version for those who are like that... ;)
(In reply to comment #11) > Is there a way to make an ebuild that points to R-patched, something like a CVS > version we have for some other packages? > > That way we can have the stable 2.2 version and the patched version for those > who are like that... ;) Sure ... just modify the current ebuild to grab the source from R-patched at CRAN. That source might not be mirrored, however -- only the "home site" in Austria may have it, since it does change daily. Also, the ebuild would need to have a step added. When you build R-patched, the tarball does not contain the recommended packages, unlike the regular released tarball. So before you do the configure, you need to "cd" to the source directory and type "tools/rsync-recommended" to download that source.
(In reply to comment #10) > however, the patches sometimes do include important updates---as they do here > for the pdf() driver. let's hope that we get 2.2.1 soon, in this case. > > of course, gentoo cannot always have all patched versions set up, but sometimes, > this is not a bad thing (see, e.g., xv). > > sincerely, /iaw I'm not sure there will be a 2.2.1, even with the severity of the PDF bug. I haven't seen anything indicating that there will be. Still, 2.3 isn't due out until spring, so it might happen. Do you know the bug number in the R archives for the PDF problem?
nope. my knowledge comes from private communication with brian ripley, who pointed out to me that weird errors from postscriptfonts in the pdf device came from some bugs that were already fixed in these patched version. regards, /iaw
(In reply to comment #14) > nope. my knowledge comes from private communication with brian ripley, who > pointed out to me that weird errors from postscriptfonts in the pdf device came > from some bugs that were already fixed in these patched version. Ah ... you clearly have a better relationship with Prof. Ripley than I do. :) He's reamed me out publicly on the R mailing lists several times, and I have given up trying to communicate with him. Meanwhile, I think an "R-patched-20051119.ebuild" is a good idea until they figure out whether there will be an R-2.2.1. It would need to be masked "~arch", right? I just rebuilt from source a few minutes ago to verify that it's as painless as it always was. Speaking of which, somewhere along the line R seems to have lost the ability to find the "Atlas" version of the blas library. "configure" now finds a "generic" blas rather than the Atlas version I have installed. At some point I'll have to dig through the R documentation to see if they did this or it's some artifact of the way I have my machine configured. There are some rather sensitive tests when you do "make check-all" that used to fail with Atlas on AMD machines, and the R team may have decided to ignore it as a result rather than deal with all the machine-dependent bug reports.
my relationship with brian ripley is not much better, I am just more persistent. he is an interesting character. very senior professor over at oxford. extremely helpful and extremely willing to be helpful, but at the same time often very gruff. he has reamed me out in public, too. fortunately, he does not seem to bear grudges, no matter how dumb my questions were. I don't know much about the details behind R or the AMD builds. I use R primarily for very simple things, and most of the time, speed is not an issue for me. bug-freeness is. yes, I think it would be great to have a base ebuild and a "late patch" build. regards, /iaw
Urggs, didn't see this Bug earlier :-/ I just bumped R to 2.2.0, but didn't add in the patches for the pdf() bug. (Hadn't encountered that one either). Marcus: What do you think of a R-2.2.0-r1 with most recent patch added? On the pro side: Anyone who wishes to use Intel Fortran to compile R can to that now by running: emerge ifc F77=ifc emerge R
(In reply to comment #17) > Urggs, didn't see this Bug earlier :-/ I just bumped R to 2.2.0, but didn't add in > the patches for the pdf() bug. (Hadn't encountered that one either). > Also, R_SHARE_DIR, R_INCLUDE_DIR and R_DOC_DIR are not fixed, which breaks translations among other things. I fixed that on http://bugs.gentoo.org/attachment.cgi?id=70240 .
As always diffs are far more useful than throwing a revised ebuild in there - a diff against the latest version shows us what the changes that you have made are. I am on the sci alias and so will get these anyway. Do you have a bug number, or more verbose description of the problem with SHARE_DIR etc?
(In reply to comment #19) > As always diffs are far more useful than throwing a revised ebuild in there - > a diff against the latest version shows us what the changes that you have made > are. I am on the sci alias and so will get these anyway. Do you have a bug > number, or more verbose description of the problem with SHARE_DIR etc? Yep. My fault. Should have posted a diff instead of a whole new ebuild. The problem with R_SHARE_DIR, R_INCLUDE_DIR and R_DOC_DIR variables is that they are being set to (sht along the lines of) /var/tmp/portage/R-2.2.0/image/usr/lib/BLABLA instead of /usr/lib/BLABLA. Naturaly /var/tmp/portage/R-2.2.0/image doesn't exist after a sucessfull emerge and R cannot find the specified paths. I've fixed the new ebuild and I'm testing it right now. As soon as I see it's ok I'll upload a diff.
(In reply to comment #12) > Sure ... just modify the current ebuild to grab the source from R-patched at > CRAN. That source might not be mirrored, however -- only the "home site" in > Austria may have it, since it does change daily. I've tried doing this before but it didn't work very well because of the m5sum checking. As far I understand the ebuild digests are updated through the portage tree. So the r-patched ebuild would have to have it's digest updated daily on the portage tree? Even if that were to be done there would be times when the md5sum wouldn't match (when the r-patched tarball was recently updated for example). That would force a manual ebuild R-patche.ebuild digest, after grabbing the sources by hand. Are you aware of other approaches to this? I think that perhaps an R-svn ebuild would be more useful than a R-patched one. This would also estimulate further testing. Don't know if the burden on the R-svn server would be too much, though.
Created attachment 73432 [details, diff] Patch against latest ebuild to fix R_SHARE, R_HOME and R_INCLUDE variables.
(In reply to comment #22) > Created an attachment (id=73432) [edit] > Patch against latest ebuild to fix R_SHARE, R_HOME and R_INCLUDE variables. > I've just tested it here and it's working fine.
How come mine are set to, R_HOME_DIR=/usr/lib64/R if test -n "${R_HOME}" && \ test "${R_HOME}" != "${R_HOME_DIR}"; then echo "WARNING: ignoring environment value of R_HOME" fi R_HOME="${R_HOME_DIR}" export R_HOME R_SHARE_DIR=/usr/lib64/R/share export R_SHARE_DIR R_INCLUDE_DIR=/usr/lib64/R/include export R_INCLUDE_DIR R_DOC_DIR=/usr/lib64/R/doc export R_DOC_DIR This is with the current ebuild for 2.2.0 in portage and none of your alterations. I was also shocked at how much this package breaks FHS by shoving stuff in the lib dir which really does not belong there! Given more time I would like to see how viable it would be to fix R to install its files into the correct directories instead of using its own file tree hidden in my lib dir.
(In reply to comment #24) > How come mine are set to, > (...) > fi > R_HOME="${R_HOME_DIR}" > export R_HOME > R_SHARE_DIR=/usr/lib64/R/share > export R_SHARE_DIR > R_INCLUDE_DIR=/usr/lib64/R/include > export R_INCLUDE_DIR > R_DOC_DIR=/usr/lib64/R/doc > export R_DOC_DIR > (...) Using the ebuild from portage, without modifications, this is what I get (in /usr/bin/R) : R_HOME_DIR=/usr/lib/R if test -n "${R_HOME}" && \ test "${R_HOME}" != "${R_HOME_DIR}"; then echo "WARNING: ignoring environment value of R_HOME" fi R_HOME="${R_HOME_DIR}" export R_HOME R_SHARE_DIR=/var/tmp/portage/R-2.2.0/image//usr/lib/R/share export R_SHARE_DIR R_INCLUDE_DIR=/var/tmp/portage/R-2.2.0/image//usr/lib/R/include export R_INCLUDE_DIR R_DOC_DIR=/var/tmp/portage/R-2.2.0/image//usr/lib/R/doc export R_DOC_DIR I can't investigate into the matter further right now as I've tons of work to do until Friday. Could it be something related to my using ia32 and you ia64? Can anyone else using ia32/ia64 check his or her /usr/bin/R ?
(In reply to comment #24) > This is with the current ebuild for 2.2.0 in portage and none of your > alterations. I was also shocked at how much this package breaks FHS by shoving > stuff in the lib dir which really does not belong there! Given more time I > would like to see how viable it would be to fix R to install its files into the > correct directories instead of using its own file tree hidden in my lib dir. I think this 'reorganization' would be pretty tricky. There's a reason for R to use it everything under this directory. The R installation takes a lot of space and several things on R depend on the file structure of the base-dir. Tipically an R installation directory, with packages, can take more than 1 gb in space. Here it takes 700 Mb in about 25000 files. Having R use a more FHS-compliant structure w/o direct efforts from the R-core members would take a lot of work and tons of patches: there would have to be changes in C code, R, code, perhaps even Fortran code.
I thought that might be the case, but I might have a quick play when I get chance. I wouldn't commit changes like that unless they had been well tested. If that is the case I don't quite understand what the point in them setting all the other variables is... If it all has to be the same layout anyway. I would like to see R conform to the FHS more, but it may well be a bigger task than me patching the ebuild a little. I will build R on my x86 system as soon as I get the chance too, but I don't understand why you are seeing temporary dirs in your version.
Forgot to close this, 2.2.1 is in the tree now and all the dir issues have been resolved already. FHS will have to wait, but it should be done...
