On 29/04/2025 18:05, Dirk Eddelbuettel wrote:
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.
i.e. r-api is the equivalent of a normal C library's SONAME (packages built with the *old* version may not work in the *new* version; recompile everything when it changes)? While dh-r is currently missing the equivalent of a shlibs version (packages built with the *new* version may not work in the *old* version; newly built packages get a Depends: on at least this version)?
I have manually added a Depends: r-base-core (>= 4.5.0~) to r-cran-svglite and r-cran-timechange, but in the longer term dh-r should probably start adding it.
| 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?
This is intended to prevent users from upgrading some packages and not others in ways that are known to break. (I agree this is unlikely, so if you don't want to I won't argue.)
We can't set a Breaks: on r-bioc-shortread or r-cran-ff because they haven't been updated, i.e. there is no fixed version.| 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: ?