Bug#1039926: Will file bug report for complete R transition (Was: Bug#1039926: svglite requires rebuild under R 4.3.*)
Hi Johannes, Am Fri, Jun 30, 2023 at 03:22:19PM +0200 schrieb Johannes Ranke: > 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. That's a good hint. I took it as resource to draft some proof of concept change for dh-r. > 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. I've filed bug #1040001 and we'll see what release team will decide. Kind regards Andreas. -- http://fam-tille.de
Bug#1039926: Will file bug report for complete R transition (Was: Bug#1039926: svglite requires rebuild under R 4.3.*)
Hi all, pardon me the offence and the noise, but I asked ChatGPT... -- Me: In Debian, updates of the r-base package sometimes break backwards compatibility with a small number of binary packages shipping CRAN packages, which have in common to use R’s graphic API. We hesitate between just bumping the version number of the r-base packages’ API, or to create a new API version scheme just for the subset of packages that are regularly broken. Which way would you recommend? ChatGPT: Creating a new API version scheme just for the subset of packages that are regularly broken might be a more efficient solution. This way, you can manage the updates for these specific packages separately without affecting the entire r-base package. However, this approach might require more maintenance work. Bumping the version number of the r-base packages' API is a simpler solution, but it might cause unnecessary updates for packages that are not affected by the compatibility issue. It's a trade-off between complexity and efficiency, and the best choice depends on the specific circumstances and resources available. -- Sorry that it was not conclusive ! Charles -- Charles Plessy Nagahama, Yomitan, Okinawa, Japan Debian Med packaging team http://www.debian.org/devel/debian-med Tooting from home https://framapiaf.org/@charles_plessy - You do not have my permission to use this email to train an AI -
Bug#1039926: Will file bug report for complete R transition (Was: Bug#1039926: svglite requires rebuild under R 4.3.*)
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
Bug#1039926: Will file bug report for complete R transition (Was: Bug#1039926: svglite requires rebuild under R 4.3.*)
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 -- http://fam-tille.de
Bug#1039926: svglite requires rebuild under R 4.3.*
On 29 June 2023 at 10:22, Dirk Eddelbuettel wrote:
|
| Package: r-cran-svglite
| Version: 2.1.1-1
| Severity: normal
|
| R 4.3.0 brought (once again) a new graphics API which requires a rebuild for
| functionality that involves creating graphics device. Once rebuilt the
| following will again work:
|
| > getRversion()
| [1] ‘4.3.1’
| > packageVersion("svglite")
| [1] ‘2.1.1’
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.
Dirk
| > svglite(tempfile())
| Error in svglite_(filename, bg, width, height, pointsize, standalone, :
| Graphics API version mismatch
| >
|
| R Core decided again not to call this a breaking change, and I concur. We may
| want to look into a graphics api tag for the next release. For now, a simple
| rebuild should do.
|
| Thanks, Dirk
|
| --
| dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
--
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1039926: svglite requires rebuild under R 4.3.*
Package: r-cran-svglite
Version: 2.1.1-1
Severity: normal
R 4.3.0 brought (once again) a new graphics API which requires a rebuild for
functionality that involves creating graphics device. Once rebuilt the
following will again work:
> getRversion()
[1] ‘4.3.1’
> packageVersion("svglite")
[1] ‘2.1.1’
> svglite(tempfile())
Error in svglite_(filename, bg, width, height, pointsize, standalone, :
Graphics API version mismatch
>
R Core decided again not to call this a breaking change, and I concur. We may
want to look into a graphics api tag for the next release. For now, a simple
rebuild should do.
Thanks, Dirk
--
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
