[R-pkg-devel] Ensuring permanence and SHA consistency of released CRAN packages for validated software

[Gábor Csárdi]

I am not speaking for CRAN, to be clear. Also, please fix me if I am
wrong, all this is based on experience.

CRAN rebuilds binary packages because of (potential) changes in
build-time dependencies. ABI changes, in the loose sense of the term.
E.g. package A can call the shared library of another package B. If
the ABI of B changes, then you need to rebuild A.

AFAICT packages are rebuilt frequently and often. E.g. if you look at
the package time stamps of the package files at
https://cran.r-project.org/bin/windows/contrib/4.2/ you see that many
(most?) of the binaries were (re)built yesterday. (If you download a
file and look inside in DESCRIPTION you'll see that it was indeed
built yesterday, the timestamp of the file is more or less correct.

Unfortunately (AFAICT) there is no way currently to tell if you have
the latest build installed and/or downloaded. The only way to make
sure that you have the latest builds of all packages is to redownload
and reinstall all of your installed packages.

This occasionally does cause issues in practice, e.g. some error
reports from users are very hard to reproduce if they happen to have
an older build of a build time dependency and that makes another
package fail.

Some time ago I suggested adding the Build field to the metadata, for
similar reasons. The Build field helps you decide if your package is
out of date or not, but a hash is obviously better, as you can also
use it to check the integrity of the package file.

One concern CRAN had with the Build field was that if
`update.packages()` used this field to decide if a package should be
updated, that would cause too many downloads.

I agree that it would be great to add the sha256 (or other) hash to
DESCRIPTION.

Gabor