[R] Failure of update.packages()

[Jari Oksanen]

On 10 Feb 2005, at 19:26, Peter Dalgaard wrote:

> plummer at iarc.fr writes:
>
>> Quoting Jari Oksanen <jarioksa at sun3.oulu.fi>:
>>
>>> On Thu, 2005-02-10 at 13:52 +0100, Peter Dalgaard wrote:
>>>> I M S White <iwhite at staffmail.ed.ac.uk> 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).
>>>
>>>> You 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.
>>>>
>>> This kind of problems were to be anticipated, weren't they? The great
>>> 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