[R] install.packages() - old version deleted, new version did not install

[Jon Olav Skoien]

On 12/20/2010 1:30 PM, Uwe Ligges wrote:
>
>
> On 20.12.2010 09:41, Jon Olav Skoien wrote:
>> On 12/17/2010 6:22 PM, Duncan Murdoch wrote:
>>> On 17/12/2010 11:13 AM, Jon Olav Skoien wrote:
>>>> Dear list,
>>>>
>>>> (R 2.12.0, Windows 7, 64bit)
>>>>
>>>> I recently tried to install a new package ("spacetime"), that 
>>>> depends on
>>>> "sp" among others. I already had the last one installed, but there was
>>>> probably a newer version on CRAN, so the command
>>>> > install.packages("spacetime")
>>>> also gave me:
>>>> also installing the dependencies ‘sp’, ‘zoo’, ‘xts’
>>>>
>>>> sp was already loaded in this session, so installation failed:
>>>> package 'sp' successfully unpacked and MD5 sums checked
>>>> Warning: cannot remove prior installation of package 'sp'
>>>>
>>>> Unfortunately, the warning should rather say:
>>>> "cannot completely remove prior installation of package 'sp'"
>>>> R managed to remove most of the prior installation of sp, except 
>>>> for the
>>>> .dll. I could go on using sp in the existing sessions, but not load 
>>>> the
>>>> package in a new session or open the help pages. This has happened 
>>>> to me
>>>> several times, and the only solution I have found to this is to close
>>>> all R-sessions and install the package again. This is normally ok, but
>>>> this time I had some long-time computations running in another 
>>>> R-session
>>>> that I did not want to interrupt. For the next time, is there a way to
>>>> reinstall a package without interrupting running R-sessions?
>>>>
>>>> For me it seems like the cause of the problem could have been 
>>>> solved by
>>>> checking if the .dll can be removed before removing the rest of the
>>>> package, by adding something like the following in 
>>>> utils:::unpackPkgZip?
>>>> if (unlink(paste(instPath,"/libs/x64/sp.dll", sep = "")) != 0)
>>>> warning("cannot remove...")
>>>> before
>>>> ret<- unlink(instPath, recursive = TRUE) (line 95)
>>>> x64 in the path would have to be changed to something architecture
>>>> dependent...
>>>
>>>
>>> Could you try out the new 2.12.1 release? I recall hearing that
>>> something like this had changed, but I can't spot the NEWS item right
>>> now.
>>>
>>> Duncan Murdoch
>>
>> It seems it didnt change yet...
>> I installed 2.12.1 (on a different computer, still Windows, but Vista
>> and 32 bit), and after installing and loading sp in one session, I
>> opened a new session and got:
>>
>> R version 2.12.1 (2010-12-16)
>> Copyright (C) 2010 The R Foundation for Statistical Computing
>> ISBN 3-900051-07-0
>> Platform: i386-pc-mingw32/i386 (32-bit)
>> ............................
>>
>> > install.packages("sp")
>> Installing package(s) into ‘C:\Users\Jon\Documents/R/win-library/2.12’
>> (as ‘lib’ is unspecified)
>> --- Please select a CRAN mirror for use in this session ---
>> provo con l'URL
>> 'http://cran.at.r-project.org/bin/windows/contrib/2.12/sp_0.9-76.zip'
>> Content type 'application/zip' length 997444 bytes (974 Kb)
>> URL aperto
>> downloaded 974 Kb
>>
>> package 'sp' successfully unpacked and MD5 sums checked
>> Warning: cannot remove prior installation of package 'sp'
>>
>> The downloaded packages are in
>> C:\Users\Jon\AppData\Local\Temp\RtmpCTJeBk\downloaded_packages
>> > library(sp)
>> Errore in library(sp) : non c'è alcun pacchetto chiamato 'sp'
>> >
>>
>> The error message is the same as earlier, there is no package called
>> "sp", the attempt to install it again removed the old version except for
>> the .dll.
>
>
>
> Which suggests there may be another R session that has the package 
> loaded (i.e. the dll locked).
>
> Just close all your R sessions and try again.
>
> Uwe Ligges
>

Yes, I know. The question was whether there is another way of 
reinstalling the missing parts, or if there is a way of avoiding that 
the package gets partly deleted when install.packages is called with the 
package itself or a dependent package.

It seems like the answer to the first is no, but a fix for the second 
one could save some trouble.

Cheers,
Jon