Re: Conflict between R 4.5 and some (mostly r-bioc 3.20) R packages
On 29 April 2025 at 18:25, Rebecca N. Palmer wrote:
| 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)?
That is not a bad analogy! And it is something one could ask upstream to
set. In practice, R upstream is done by a team which has its ways and
changing something that has worked for decades (i.e.: no encoded soname) is
not all that likely to change.
| 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)?
The packages I maintain have always added the Depends (in almost the same
form you use, I just don't bother with the final tilde as I know here will
always be a Debian 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.)
Yes, I suspected just that, and the motivation is not a bad one. I just
prefer to use a lighter touch so I do not rush to imposing versioned
constraints (or Breaks). This near-release quasi transition is a good reason
though.
| > | 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: ?
| 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.
Doh. Makes sense.
Ok, I will upload a fresh 4.5.0-3 with the Breaks you argued for. Fingers crossed!
Cheers, Dirk
--
dirk.eddelbuettel.com | @eddelbuettel | edd@debian.org
Reply to: