[R-pkg-team] Bug#1039926: Will file bug report for complete R transition (Was: Bug#1039926: svglite requires rebuild under R 4.3.*)

Johannes Ranke johannes.ranke at jrwb.de
Fri Jun 30 14:22:19 BST 2023


Hi,

I think option 1 from [1] is the way to go, i.e. make r-base provide a 
graphics API version according to the R changelog, and have the relevant 
packages depend on that graphics API version. How to identify them was 
discussed previously on this list [2]. Using the codesearch and github URLS 
provided in that email, the list given there could be updated.

Somehow Dirk is hesitant to do this, I think it is just a matter of "is this 
really necessary"? To me, it seems there is ample evidence by now that it is 
indeed necessary, for the mental sanity of everyone involved, and to avoid 
future discussions about a full R API bump just because of the graphics API on 
the one hand, and to avoid breaking things by just ignoring the issue on the 
other hand.

Kind regards,

Johannes


Am Freitag, 30. Juni 2023, 14:01:55 CEST schrieb Andreas Tille:
> Hi Dirk,
> 
> Am Thu, Jun 29, 2023 at 05:52:34PM -0500 schrieb Dirk Eddelbuettel:
> > This accidentally omitted
> > 
> >         library(svglite)
> > 
> > The package loads fine, but like the others will not create a graphics
> > device as it was built under the previous R 4.2.* series.
> 
> Thanks a lot for your specific bug reports to somehow heal the R
> graphics ABI change issue.  I've got the impression there is no good
> simple rule to detect the right set of packages that need rebuilt
> against r-base 4.3.1 to fix this issue.  I also spotted that vdiffr
> needs to be rebuilt to let ggplot2 passing its test suite (and so I
> did).
> 
> Thus I think it is the best solution to ask the release team for
> a full r-base transition (option 2 I suggested in [1]).
> 
> BTW, when I was running the autopkgtest of svglite I've spotted an issue
> which was solved by Nilesh Patra and reported as #1039955.  I'd like to
> make you remind this kind of situation if you might fall back into your
> "do not test Debian packages, rather trust CRAN" pattern in future.  We
> do not run tests against CRAN code (despite we had spotted mistakes even
> there in the past) but we are testing Debian packages which is a
> different thing.
> 
> I also spotted vdiffr because of the autopkgtest in ggplot2.  It makes
> simply sense to test what we are shipping before we ship it to our
> users (specifically if we as Debian maintainers like I am are not at
> all R experts as I expressed several times).
> 
> Kind regards
>     Andreas.
> 

[1] https://lists.debian.org/debian-r/2023/06/msg00025.html
[2] https://lists.debian.org/debian-r/2022/04/msg00018.html



More information about the R-pkg-team mailing list