On 10 Feb 2005, at 19:26, Peter Dalgaard wrote:
[EMAIL PROTECTED] writes:
Quoting Jari Oksanen <[EMAIL PROTECTED]>:
On Thu, 2005-02-10 at 13:52 +0100, Peter Dalgaard wrote:I M S White <[EMAIL PROTECTED]> writes:
Can anyone explain why with latest version of R (2.0.1) on FC3, installed
from R-2.0.1-0.fdr.2.fc3.i386.rpm, update.packages() produces the message
/usr/lib/R/bin/Rcmd exec: INSTALL: not found.
Indeed /usr/lib/R/bin seems to lack various shell scripts (INSTALL, REMOVE, etc).
This kind of problems were to be anticipated, weren't they? The greatYou need to install the R-devel package too: 1 R-devel-2.0.1-0.fdr.2.fc3.i386.rpm
The big idea is that this will suck in all the required compilers, libraries, and include files via RPM dependencies, but users with limited disk space may be content with the binaries of R+recommended packages.
divide between use-only and devel packages is a rpm packaging standard,
but not very useful in this case: it splits a 568K devel chip from a
15.4M chunk of base R. Moreover, you don't have a repository of binary
packages for Linux which means that not many people can use the 568K
saving in download times (saving in disk space is more considerable of
course). So are there plans for binary Linux packages for other distros
than Debian so that people could use the non-devel piece of R only?
cheers, jari oksanen
The splitting is an experiment (and I said so when I announced it).
It does have unforseen consequences, like implicating me in maintaining a
repository of binary RPMs for CRAN packages, which I'm not particularly keen
on.
So I shall probably revert to a single RPM, and force the installation
requirements to be the same as the build requirements. This was, in fact,
Peter's suggestion which shows that not everybody is as short-sighted as me.
Martyn
Hmm... Actually, you had sort of convinced me that the split might be a good idea. Point being of course that it's not the 568K that gets shaved off in R-devel, it's the 12M for gcc + the 5M for g77 + 28M for perl + more, which are only needed for installing packages and are therefore not dependencies of the main R RPM. Maintaining binary package RPMs was never in the cards as I saw it. However, it then only makes sense if a sizable proportion of R users are never going to install packages. Otherwise you get cost of having to explain the point repeatedly, at basically zero benefit.
That's a good point. You could look at MacOS X standard installation to see what can be left out in a working installation. In default Mac, you don't have gcc (12M), nor g77, but you sure need perl for a sensible working machine, and tha't in default MacOS X installation. The price is that you need a possibility to install binary R packages. So not so much saving, but a bit more than what you get by shaving off R-devel.
cheers, jari oksanen -- Jari Oksanen, Oulu, Finland
______________________________________________ [email protected] mailing list https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html
