Re: Conflict between R 4.5 and some (mostly r-bioc 3.20) R packages
On 29 April 2025 at 16:53, Rebecca N. Palmer wrote:
| How was it decided that R 4.5 didn't require incrementing r-api?
The r-api field is for actual API changes. R 4.0.0 required a rebuild of
everything, packages would not work otherwise. That was sclearly communicated
by upstream. Such changes *requiring rebuilds* are rare. I think we had
about three in the 25 or so years I have looked after the package (as
co-maintainer or maintainer), and 4.0.0 was the last such change.
Under normal annual updates of R (i.e. when the minor version changes) the
rebuild is not required, and simply adding a Depends: in the client package
is usually fine. What you otherwise see is a warning 'package FOO was built
under version X.Y.Z' when when X.Y.Z is larger than what you currently run
(i.e. R 4.4.* running a R 4.5.0 build).
| On 29/04/2025 14:24, Dirk Eddelbuettel wrote:
| >
| > On 29 April 2025 at 13:47, Rebecca N. Palmer wrote:
| > | Ideally r-base should be re-uploaded with
| > |
| > | r-base-core Breaks: r-bioc-bioccheck (<< 1.42.1+dfsg-2~), r-bioc-graph
| > | (<< 1.84.1-2~), r-bioc-iranges (<< 2.40.1-3~), r-bioc-pwalign (<<
| > | 1.2.0-3~), r-cran-rlang (<< 1.1.5-2~), r-cran-testthat (<< 3.2.3~)
| >
| > r-bioc-graph, r-bioc-irange[s],
|
| These are not on the excuses list because their fixed versions have
| already migrated to testing.
Ok. I still find this a bit odd. If the fixed versions are in testing (as eg
with r-bioc-graph) do we really need a Breaks: on it?
| r-cran-rlang, r-cran-testthat are
| > not on the current excuses page [1] However, r-bioc-shortread and r-cran-ff
| > are and they are missing from that list.
|
| r-bioc-shortread is fixed by changes in r-bioc-pwalign; r-cran-ff is
| fixed by changes in r-cran-testthat.
And the release team will know how to connect those dots? Or should we help
with an expanded Breaks: ?
|
| (I'm not sure why r-cran-rlang isn't on the excuses list: possibly
| because the autopkgtest that considered migrating them together was run
| after the one that considered migrating r-base alone.)
I can add the Breaks you suggested (we have done this before as the
debian/control still shows (and per 'git blame' last in July 2023, so we're
ahead this time) but I would prefer to only have to do it once.
And I currently do not fully grok if the list you suggested is sufficient per
the discussion here. So your help and guidance continues to be appreciated.
Dirk
--
dirk.eddelbuettel.com | @eddelbuettel | edd@debian.org
Reply to: