I was wondering: are the downstream dependencies of a package rebuilt
when a package is updated on CRAN? (I'm referring to the binary
packages, of course.)
The reason I ask is because there are cases where this can cause
problems. Suppose that when pkgB is built, it calls
pkgA::makeClosure(), which returns a closure that refers to a function
in pkgA. Suppose this code is in pkgA 1.0:
makeClosure <- function() {
function() {
funA()
}
}
funA <- function() "funA was called!"
And this is the code in pkgB:
foo <- pkgA::makeClosure()
After building and installing pkgB, you can do this, which gives the
expected result:
> pkgB::foo()
[1] "funA was called!"
Now suppose pkgA is upgraded to 2.0, and it contains this:
makeClosure <- function() {
function() {
newFunA()
}
}
newFunA <- function() "newFunA was called!"
After this upgrade, when you run the pkgB::foo(), you'll get an error:
> pkgB::foo()
Error in foo() : could not find function "funA"
This is because the environment for pkgB::foo is the pkgA namespace,
but the contents of that namespace have changed underneath it. The
solution is to rebuild and reinstall pkgB against pkgA 2.0.
This is why I'm asking about downstream dependencies being rebuilt on
CRAN. If pkgB's binary packages are not automatically rebuilt when
pkgA is updated on CRAN, then there would be a broken combination of
pkgA and pkgB on CRAN. (Note that source packages aren't vulnerable to
this problem)
This is not a purely academic exercise -- something similar to this
has actually occurred. When R went from version 3.0.0 to 3.0.1, there
was a new function in the methods package named .setDummyField, and
reference class objects that were built against methods 3.0.1 received
closures that included calls to .setDummyField(). If these refclass
objects were saved in a package at build-time, then they would not
work on systems with R (and methods) 3.0.0. Because CRAN built
binaries on R 3.0.1 after its release, users who were on R 3.0.0
simply could not run some binary packages from CRAN. Their possible
solutions were to upgrade R, or install the packages from source. I
know this happened with Shiny, lme4, ROAuth, among others.
https://groups.google.com/forum/#!msg/shiny-discuss/poNAAtyYuS4/n6iAVMI3mb0J
https://github.com/lme4/lme4/issues/54
http://stackoverflow.com/questions/18258087/twitter-error-when-authorizing-token
It happens that the methods package is included with the base R
distribution, but this kind of problem can occur with other packages
as well.
Many of us have encountered hard-to-diagnose problems that are solved
by reinstalling R and all packages. I suspect that this is the root
cause in many of those cases.
At the very least, it would be nice to be able to specify in a pkgB
that it depends on pkgA in such a way that it must be rebuilt when
pkgA is upgraded. There are two important consequences of this: CRAN
would need to rebuild pkgB when a new pkgA is accepted; and when users
upgrade pkgA, they would need to receive a rebuilt pkgB as well.
-Winston
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
