Re: Seems we need a transition for r-base instead of lots of single bugs against single packages (Was: Bug#1039645: r-cran-epi: autopkgtest failure with r-base (4.3.1-1))
On 28 June 2023 at 20:55, Nilesh Patra wrote:
| Looking at the NEWS section of R release here[1] gives me the impression
| that a bunch of things have changed between 4.2->4.3 so most definitely,
| a few CRAN packages need recompilation. To pick out one instance of it,
| the doc says:
|
| | GRAPHICS:
| | • The graphics engine version, R_GE_version, has been bumped to 16 and so packages
| | that provide graphics devices should be reinstalled.
|
| This is a good indication that packages in debian that use graphics API
| (like cairo or ggplot) which are compiled against 4.2 would not work
| with the new 4.3, which is also confirmed from the autopkgtest failures
| for the same.
That is correct, and someone (on one of the R lists) posted a search query eg
for GitHub's 'cran' org which is de facto a mirror of CRAN (and a superset as
CRAN retires packages but that org does not delete them). If we can batch
search our git repo you can find them too. For r2u I think I only needed to
explicitly rebuild svglite and ragg but I didn't keep notes.
| I agree that doing binNMU for arch:any packages that need re-building
| makes sense. However, in a few cases these packages also have a new
| upstream release, which is compatible with a new r-base release.
| Hence, we have to go ahead and update then anyway.
That has always been my pragmatic take. Given the freeze many packages need
either a catch up if they lag, or a rebuild from experimental. I did that for
mine.
Dirk
--
dirk.eddelbuettel.com | @eddelbuettel | edd@debian.org
Reply to: