Copying packages between minor versions of R can result in broken packages

[DavisVaughan]

It seems like copy.packages.between.libraries() can, for example, copy packages from R 4.1.3 over into a package library for R 4.2.0.

installr/R/updateR.R

Line 589 in eb2bdc3

copy.packages.between.libraries <- function(from, to, ask = FALSE, keep_old = TRUE, do_NOT_override_packages_in_new_R = TRUE) {

I think this is going to cause problems for a lot of people, as packages built with different minor versions of R (4.1 -> 4.2) are not compatible with each other. See this section of the R Windows FAQ:

https://cran.r-project.org/bin/windows/base/rw-FAQ.html#What_0027s-the-best-way-to-upgrade_003f

2.8 What’s the best way to upgrade?
That’s a matter of taste. For most people the best thing to do is to uninstall R (see the previous Q), install the new version, and then there are two options what to do with the library.
The simpler but more resource intensive one is to install all required packages again with the new version of R and then delete the old library once you no longer need it e.g. for reference. Sometimes, this is necessary when there is a change in R that makes the installed packages incompatible, such as when upgrading from R 4.1 to R 4.2 (installed packages with native code/DLLs are incompatible). Also, installing packages can be very fast when they are distributed in binary form (e.g. from CRAN or Bioconductor).
A previously recommended option was to copy any installed packages to the library folder in the new installation, run update.packages(checkBuilt=TRUE, ask=FALSE) in the new R and then delete anything left of the old installation. Different versions of R are quite deliberately installed in parallel folders so you can keep old versions around if you wish. This would often work, but not e.g. when upgrading from R 4.1 to R 4.2, in that case one could do this only for packages without native code/DLLs.

This kind of problem has resulted in frustrated Windows users with multiple packages:

• Error: CCTZ: Unrecognized output timezone tidyverse/lubridate#1041 (comment)
• Setting timezone parameter in dbConnect throws an error (R 4.2.0 only, Win) r-dbi/odbc#495

I don't know if they used installr to update, but it seems like they have a situation that could have been caused by this issue.

Is there any way you could discourage usage of this function, or remove it entirely?

[burgerga]

I agree with removing; clean installing prevents a lot of annoying problems. NB above issues could have been caused by installr, but especially for Windows (e.g., institute-managed computers) another possible culprit could be using a non-R-version-specific R_LIBS_USER (as unfortunately is common in our institute :( )

[DavisVaughan]

I just got confirmation from the lubridate user that they used installr when they updated, so their frustration was probably because of this issue tidyverse/lubridate#1041 (comment)

[Alternikaner]

R_LIBS_USER was the culprit in my case. I'm on a corporate system where shared/network/virtual drives are increasingly being used, particularly for common Windows locations - some of them with limited write permissions. This wreaks havoc on some package installs, which could be avoided by specifying a local package directory. It never occurred to me that "up-to-date" packages built in prior versions could be problematic. Hopefully this workaround won't be required given the change to the default Win package location in 4.2