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

[Iñaki Ucar]

Please, note that the mailing list strips out all the HTML from the
messages (see the posting guide [1]). It's difficult to follow the
conversation if there's no explicit marker for the text that is being
cited.

[1] https://www.r-project.org/posting-guide.html

Iñaki

On Mon, 21 Mar 2022 at 14:15, Borini, Stefano
<stefano.borini using astrazeneca.com> wrote:
>
> 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/<https://cran.r-project.org/bin/windows/contrib/4.2> you see that many
> (most?) of the binaries were (re)built yesterday.
>
> Well, the binaries it’s a different story and needs its own solution. I am referring to the source packages, not the binary ones. So I suspect that when the binaries are rebuilt, the DESCRIPTION file in the source package is updated as well by the build system.
> That’s what creates the issue.
>
> 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.
>
> You can’t do that because then you would end up in a chicken egg situation where the sha of the tgz package depends on the content of the DESCRIPTION which would depend on the sha of the package.
>
> Do you want me to study in more details on how it’s worked out in python? We could come up with a similar strategy, but I hardly doubt it will be implementable quickly and effortlessly.
> Probably the easiest strategy is to have a gpg signature for each package, but it can get heavy for maintainers at CRAN, and it still does not really solve the problem if it’s automated. Whatever changes the source DESCRIPTION file, will have to repackage the source tar.gz, and then sign it anew.
> ________________________________
>
> AstraZeneca UK Limited is a company incorporated in En...{{dropped:24}}