Hi Brendan,
I'd like to tag Ricardo and to this and ask: Since you are
taking a break, can you reflect back at your process for
updating R, look at your shell history, and ask what
knowledge you have that someone else trying to update R
themselves would have to need to know to learnt how to do it
from scratch, and then document it all, if it
isn't already?
I used to update all of CRAN and Bioconductor with "./pre-inst-env
guix refresh -t {cran,bioconductor} -u", fix the updated package
definitions (e.g. to restore undeclared inputs for replacing
minified JavaScript), check that all of them build, and then push
them to the "r-team" branch.
I depend on the output of "git diff" (from within Emacs Magit) to
identify obvious problems introduced by the updater, such as
removed JavaScript inputs or extremely long additions of native
inputs. The former is a result of poor upstream practices:
JavaScript inputs are generally not declared in the packages'
DESCRIPTION files and are often treated as an opaque minified
blob. The latter is due to overly simplistic heuristics in the
updater/importer, but they are easy to correct. Some package
updates lead to dependency cycles, often just because of overly
zealous additions to the native inputs. I update the properties
to instruct the updater to skip those problematic inputs in the
future.
Once there are no more dependency cycles I check if there are
missing inputs anywhere by running "make". I then add those
packages first, or try to do without them if they are troublesome.
When there are no missing inputs and no cycles I either build
everything locally and eventually push my updates to the r-team
branch. I then observe failures in the r-team jobset on
ci.guix.gnu.org, and fix those. Finally, I rebase the whole set
of changes, rebuild again, then merge.
For updates to R itself (= r-minimal and r-with-tests) I build the
hidden r-with-tests once and r-minimal with "--rounds=3 -K" to see
if there are reproducibility problems. A single character
difference in a generated package description is not uncommon, but
I haven't found a way to fix it. When this works I push to r-team
and let the build farm build out all R packages.
In any case: at the start of my work I record a request to merge
the r-team branch. I usually finish the work well before it would
be the R team's turn to merge the branch. There is often at least
a month between opening the request and being allowed to merge,
sometimes even up to three months pass.
I don't know if this is worth adding as a cookbook chapter,
because unlike the rust team's process it's pretty mundane. But I
wouldn't object to appending it to the cookbook if someone
considers it valuable information.
--
Ricardo
