This is not a bug in r-base, and does not warrant a transition.
I have written at some length about it, and (if I find some time) will expand
on it in blog post. I will also try to coordinate with upstream.
In short, R header GraphicsEngine.h [1] defines an integer constant declaring
the current versions capabilities. Graphics device packages can then opt
into what they support using conditional code. Or they can opt into checking
and aborting on any mismatch via R_GE_checkVersionOrDie (for
'R_GraphicsEngine_*)
void R_GE_checkVersionOrDie(int version)
{
if (version != R_GE_version)
error(_("Graphics API version mismatch"));
}
Which some packages do. Note that the packages _load_ and _function_ (in a
limited sense). They "simply" do not act as a graphics device, and alert the
user to rebuild the package.
So per upstream ("R Core" for short), this is clearly on the package
side. There is no ABI/API incompatibility: R offers graphics functions new
functionality, to use it one needs a rebuild _if a package decides to stop
and die on mismatch_.
I so filed three bug reports last weekend against three such packages
requesting a simple rebuild as that is in fact all it takes. (And
missed one that was added.) These were quickly rebuilt.
And as a consequence the 'excuses' list for r-base is shrinking now just as
one could expect [3]. In particular a number of packages from the ggplot2
complex are now all green ... with the exception of s390x where eg ragg (used
often in unit tests) is awaiting a rebuild [4]. Once s390x rebuilds those
packages will turn green leading into to their dependents turning green/
So in short, in my view as maintainer, a transition is overkill and a waste
of resources, cpu cycles and otherwise. I am rather confident it will
straighten itself out. (There may still be other issues with the
BioConductor release transition but I also expect those to be package-caused
and solvable.)
So let me know what you think. If the release team thinks we must rebuild
across 1100 r-* packages (of which likely 400-500 are Architecture: any)
then I will of course work with you.
But I maintain that it is not caused by the package, and not needed, as it is
a set of client-package-local differences these packages opt-in upstream and
which are solvable with a simple rebuild of those packages. Now, I
understand that _for simplicity_ we want to use this very blunt tool. But I
am old enough to remember that we also value engineering excellence. As
there is no need for brute force, I advocate against it. No more, no less.
Cheers, Dirk
[1] For us at /usr/share/R/include/R_ext/GraphicsEngine.h
[2] In the sources at src/main/engine.c
[3] https://qa.debian.org/excuses.php?package=r-base
[4] https://buildd.debian.org/status/package.php?p=r-cran-ragg
--
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
