[R-pkg-team] Bug#1035428: Test suite issues due to new upstream version of r-core in unstable (Was: r-cran-shiny: broken symlink: ...)

[Dirk Eddelbuettel]

On 16 May 2023 at 15:01, Andreas Tille wrote:
| Hi,
| 
| when fixing bug #1035428 I realised test suite issues with
| 
|   r-cran-thematic [1]
|    -> Error in `svglite_(filename, bg, width, height, pointsize, standalone, 
|       always_valid)`: Graphics API version mismatch
| 
|   r-cran-treescape [2]
|   r-cran-treespace [3]
|    -> error is given if lambda is outside of [0,1] ---
|       `medTree(trees, -1)` did not throw an error.
| 
| As far as I can guess at least the first type of error (Graphics API
| version mismatch) is caused by the fact that a new upstream version of
| r-base (4.3.0-1) was uploaded to unstable (changelog[4] says to
| experimental so it seems by accident).

Yes. It was very much by accident, and my bad.

When the freeze hardened and I switched uploading from unstable to
experimental (on March 15 per my mail folder of installer replies, and
coincidentally with the R 4.2.3-1 upload), I managed to update the
distribution field (often using 'C-x d' in the handy Emacs mode) in the
debian/changelog file each and every time --- with the one exception of
the next update of r-base to the 4.3.0 release :-/
 
| I wonder what might be the most sensible strategy to fix this.  Since
| an epoch is considered ugly I've seen some kind of
|     4.3.0+really+4.2.2.20221110
| version number.  However, in case of R it might not be the best idea
| to use this kind of fake version in a stable release.

I think we shouldn't. Apart from this test issue, the binary sits in unstable
and will remain in unstable.

The change is graphics format is a repeat of previous micro-API changes from
upstream where Paul Murrell (who is the one taking care of the graphics
device) enhances its capabilities (often in quite meaningful ways).  The R
Core team does not consider this a breaking change, and does recommend or
mandate rebuilds of the nearly 20k CRAN packages. I happen to concur.

However, when a package built with such a graphics api version 'A' is loaded
by R of version 'B' (and it usually happens to us the other way) the package
load simply errors out with a message.  This is not fatal -- it is just a
hint to rebuild the package under the R version used.  I have always been of
the pragmatic view that is indeed good enough. (Johannes of the back-porters
team disagrees, he reminded me of a simple search for the one code line doing
the check. Running that at the GitHub mirror of CRAN (which is a superset as
it includes packages that once were on CRAN but are no longer) I identified
ten packages of which about half or more are no longer on CRAN.  For us it is
likely `ragg` and `svglite`. I can dig out the details from my reply to
Johannes.)

Note that none of this affects the release. My recommendation is temporarily
suspend the autopkgtest in those affected packages.  They did their job and
found the mismatch with the R 4.3.0 in unstable that shouldn't have been
uploaded there. Out the about fifty package uploads I made since I switched
to experimental, one went to wrong repo. That was not intentional but I think
we can manage.

Best, Dirk

-- 
dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org