The ebuild for dev-lang/R installs two files which ought to be the same? Ie. /usr/bin/R and /usr/lib/R/bin/R. Unfortunately they're not as /usr/bin/R executes nicely whereas /usr/lib/R/bin/R yields the error message "R_HOME (`/var/tmp/portage/R-1.5.1/image//usr/lib/R') not found" This has the following implications: automatic updates of additional R packages from within R using install.packages() does not work as the function install.packages calls /usr/lib/R/bin/R instead of /usr/bin/R (on a side note: shouldn't R be moved to app-sci?)
Hi kdh Thanks for the bug report! Ok, upon the look into both those R's I can tell that these are bash wrappers that are supposed to invoke R.bin. The only difference is R_HOME_DIR setting, which gets corrected in one of these but not the other. I corrected the ebuild to modify R under /usr/lib/R/bin and to symlink it into /usr/bin Please test and report if that solves the problem, I am masking the ebuild for now. George
I've checked the new ebuild and it does indeed work, eg. install.packages("foreign") does work from within R. However as I'm not too familiar with the inner workings of gentoo, here is what I did in order to reinstall R: emerge unmerge R emerge rsync in order to remove R and get the ltest protage tree. Now emerge search R yields that the present persion availible is 1.4.1. I then edit /usr/portage/profiles/package.mask and comment the line dealing with R out. Then I do emerge R and it installs R version 1.5.1. However it does not download the source files anew - I guess this is normal as the changes have been to the ebuild script and not the source .files kdh
Hi. Thanks for testing! Yes, everything you did was correct (you could just emerge it over existing version, but doing unmerge followed by emerge sometimes can give a cleaner result (identical in this case)). As I indicated, ebuild was masked, so you (correctly) unmasked it by commeting out its entry in the package.mask. Sources are not fetched again since you already have them. All the modifications introduced by gentoo developers are indeed stored as patches or parts of ebuilds in your [local] portage database. I am unmasking the ebuild and closing the bug now after successful testing. George