How to trace a corrupt package



Just for reference say I download a package x and it downloads some dependencies y1, y2 , y3 and so on... and one of which is broken and I have some of my packages which are dependent upon that as well. How can I trace which package to reinstall to set up everything just fine. I know it's out of context but it is an information I think as an R programmer I should know.

It happened yesterday while installing ggplot2 dev version Rlang created some issue and I was not able to understand why I can't plot even after reinstalling ggplot2 again and again.Because it can happen again too....

It's just a formal discussion. Let me know how do you some it.


I have faced this same exact issue with the development version of ggplot2. My solution was just to remove the packages and reinstall the stable versions. To me, it wasn't worth the headache of trying to figure it out, although i would like to know if someone has a solution. I just figured I would comment to say that I think this might be a common thing.


For context, this topic emerged out of this other thread. As co-conspirator, I’d like to say that I’m interested in the generalizable strategies other people take to diagnose package installation and dependency problems and in resources for learning/teaching people how to handle these problems with confidence.

To expand a little on what I said in the original discussion, I feel like long, incremental experience has given me an empirical skill set that boils down to:

  • knowing how to parse info out of R error messages and warnings
  • an intuition for where the likely points of failure are that I can’t articulate well

But I don’t really have a coherent theory to underpin this hard-won experience, I find it hard to teach to anybody else, and I strongly suspect I have a lot left to learn! I also don’t know of any beginner-friendly go-to resources on the topic.

I think dealing with this stuff in the R ecosystem is a lot easier than in some others I’ve dabbled in, but I still see plenty of people stumble on it, and with the rise of install-from-github it seems to be getting more complicated. So, my questions:

  • What’s your debugging/diagnostic stragegy for package installation and “dependency hell” issues? Do you even have a strategy, or do you just rip it all out and reinstall every time?
  • Are there good resources out there for helping less experienced useRs feel confident handling installation and dependency problems?


How did you figure out that you need to remove rlang and reinstall it as well. Because in my case I was removing and installing ggplot2 again and again and it didn't work.

It's there any pattern I should know of...


What I want to know is

  1. Can I know what packages have been changed recently.
  2. Can I switch back to exactly those version of some packages which were working fine after I figure out these have been changed.


What error message were you getting @Anantadinath?

My strategy is to read error messages.

Most of the time, if I encounter a problem with a package, it is during installation (package does not install). I am not sure what it looks like when installing packages from within RStudio, but I imagine that the console probably displays the same output that would show if installing straight from within R? If so, check what is happening when packages are being installed. It isn't just jiberish. It is really useful information. I don't want to give recommendations about RStudio, but it might be better to install packages directly in R anyway (rather than RStudio). I use another interface to R, but when I install, update, remove, re-install packages, I do it in a session with administrative privilege and I do it directly in R.

When installations fail, this is given at the end, with a warning. But if this happens while installing or updating several packages, the relevant information can be thousands of line up. So I usually keep an eye on what is happening during install and when a line starting with "ERROR:" pops up, I stop the screen by clicking on it. This is where R will tell you that the installation of x failed because it could not load y1 for instance (maybe because it was compiled under another version of R). So now I know that I need to recompile y1. And maybe I will get an "ERROR:" then again, because z3 also needs to be recompiled. It can be a little tedious, but the info is all in there. With the release of R 3.5 for instance, since many packages needed to be recompiled, I kept running into chains of dependencies. So I opened a little text file in which I wrote: x: y1: z3, etc. Meaning that when trying to install x, it failed because of y1. And when trying to install y1, it failed because of z3, etc. Eventually, you get to a package that successfully installs, so you can start "walking" that chain back up towards x.

It is extremely rare when I encounter a problem with a package that successfully installed. But there again, the answer is in the error message. I can in fact only recall one such instance and it was with lintr. The error message was:

Error in dyn.load(file, DLLpath = DLLpath, ...) : 
  unable to load shared object '/usr/lib/R/library/stringi/libs/': cannot open shared object file: No such file or directory

This error tells me that the issue has to do with the package stringi. I re-installed stringi and the problem was fixed.

When installing packages from a command line (R or otherwise), it might feel overwhelming to see thousands of lines of stuff scroll down at high speed. It is easy to think of it all as unintelligible stuff. But it is not. And things like "ERROR", "can not load ...", "package was compiled under another R version", etc. do make sense.


Do you mean on your system? If so, yes: you only have to open your library folder and check the "modified" dates.


If they are still available online somewhere or if you kept the install files, then yes. devtools offers lots of options and even the base install.packages() has quite a few options.

This should be useful:


Thanks for this information I think that Might be helpful in future cases. Thanks again.