Skip to content

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

17 messages · Uwe Ligges, Jon Olav Skoien, Duncan Murdoch +2 more

#
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...

Best wishes,
Jon
#
On 17/12/2010 11:13 AM, Jon Olav Skoien wrote:
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
2 days later
#
On 12/17/2010 6:22 PM, Duncan Murdoch wrote:
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.

Jon
#
On 20.12.2010 09:41, Jon Olav Skoien wrote:
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
#
Jon Olav Skoien wrote:
Did you have it open at the time?  Windows won't let open files be 
removed, so that could have caused the problem.  If it's not that, it 
could be a permissions problem.  Have you tried running R as 
administrator for the install?

Duncan Murdoch
#
On 12/20/2010 1:30 PM, Uwe Ligges wrote:
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
#
On 12/20/2010 1:43 PM, Duncan Murdoch wrote:
Yes, I had it open. In this case it was intentional to give a 
reproducible example in case something had changed in the new version, 
in other cases I have had to wait for 2 days before I could reinstall a 
package. It seems the .dll is the one causing the problem, so wouldnt it 
be possible to test if this file can be unlinked before trying to unlink 
the complete directory in utils:::unpackPkgZip? Then the package should 
be left untouched if it is in use, and not partly deleted as today.

I know that it is possible to avoid this problem by not installing a 
package in use, but
1) it seems only to affect packages with .dll's, so some packages can be 
reinstalled while in use
2) you dont always know if a dependent package will download a new 
version of an installed package

Best wishes,
Jon
#
On 20/12/2010 9:03 AM, Jon Olav Skoien wrote:
I don't know.  Perhaps we could try to rename the folder; if that fails, 
abort the whole thing.  If that succeeds but something later fails, then 
remove all the new stuff and restore the old folder.  Do you know of a 
better test?

Duncan Murdoch
#
On 20.12.2010 15:19, Duncan Murdoch wrote:
I think we had something like that in the past which did not work 
properly on network shares and we had to change the way it works for 
that reason.

Uwe
#
On 20/12/2010 9:26 AM, Uwe Ligges wrote:
I just took a look at the code, and I see that something like that is 
still there.  I haven't tried it yet, so I don't know if it is in use.

Duncan Murdoch
#
On 20/12/2010 9:29 AM, Duncan Murdoch wrote:
[ lots deleted ]
After a closer look I see that the code is there for source installs, 
but not binary installs.  For binary installs the procedure is:

  unzip the package to a temporary directory
  look at the DESCRIPTION to find the package name (since you can't 
trust the .zip name)
  abort if the package is in the search list.  (This is the test that 
could be stronger, because it doesn't detect a package in use in another 
instance of R.)
  remove the old package if it is there.  (This is the step that removes 
everything but the old DLL when the DLL is in use.)
  copy the new package into place. (This fails because of the collision 
with the old DLL.)

I'll look into strengthening the test at the 3rd step with something 
along the lines described above.  From Uwe's description, this might 
still not
be perfect, but it should help with local installs.

Duncan Murdoch
#
This sounds like a good solution for the case I described in my first 
email.

Thanks a lot!
Jon
On 12/20/2010 4:05 PM, Duncan Murdoch wrote:
#
I've just tentatively put code to fix this in place in R-devel.  By 
default it is not enabled, because if it goes wrong it could really mess 
things up.  To enable it, set

options(install.lock=TRUE)

before installing or updating binary packages in Windows.  It will slow 
down all installs, so it may be that the default should stay no-locking 
as it is now:  only people running multiple instances of R really need this.

Since it appealed to my sense of symmetry, you can also say

options(install.lock=FALSE)

which will mean that source installs done by install.packages() will 
default to act like R CMD INSTALL --unsafe, i.e. go ahead without 
locking.  The latter change affects all platforms, not just Windows.

You should be able to download R-devel builds containing this change by 
tomorrow; look for revision r53875 or newer.

Duncan Murdoch
On 17/12/2010 11:13 AM, Jon Olav Skoien wrote:
#
Andy Zhu wrote:
I think your analysis is wrong. The path to Rtools/MinGW/include is not 
explicitly set by R.  You set the PATH to the compiler, and that include 
directory is automatically set.

Duncan Murdoch
#
This is simply misinformation.  The Rtools distribution does include 
g++ suitably configured for static linking of libstdc++, and that 
works for the hundreds of CRAN/BioC packages using C++.

And please report bugs in packages to their maintainers, not here.
You do not need to include the paths to MinGW's include and lib 
directories in Makevars.win, so that package should not have them.
On Tue, 21 Dec 2010, Andy Zhu wrote: