Re: Conflict between R 4.5 and some (mostly r-bioc 3.20) R packages
On 21 April 2025 at 19:18, Rebecca N. Palmer wrote:
| r-base 4.5.0 is currently blocked by 3 r-cran* and 6 r-bioc* packages.
Thanks for bringing this up. As the one who looks after r-base this is a
recurrent point of friction.
| r-cran-ff and r-cran-pillar pass with R 4.5.0 in unstable but fail with
| R 4.5.0 in otherwise-testing, which suggests that they'll be fine if
| some other package migrates. I haven't tried to find out which one.
Good catch. Could possibly be testthat or rlang. Also few tests: for ff it is
just one out of 900+, for pillar it is shenanigans with subprocesses (why ?).
| r-cran-rlang, r-bioc-graph and r-bioc-iranges fail with R 4.5.0 in both
| unstable and otherwise-testing. Rebuilding r-bioc-graph and
| r-bioc-iranges with R 4.5.0 succeeds but doesn't help:
| https://salsa.debian.org/r-pkg-team/r-bioc-iranges/-/jobs/7472123
| https://salsa.debian.org/r-pkg-team/r-bioc-graph/-/jobs/7472135
| I haven't tried rebuilding r-bioc-biocgenerics with R 4.5.0, which might
| help. (Caution: to avoid potentially making the situation worse, please
| do *not* upload any such rebuilds to sid until we know more about
| whether they'll help.)
|
| r-bioc-delayedmatrixstats, r-bioc-pwalign and r-bioc-shortread also
| fail, but depend on r-bioc-iranges so might be the same bug as that,
| though only r-bioc-delayedmatrixstats is failing with an obviously
| iranges-related error message.
It would be good to unplug this and get R 4.5.0 migrated. My approach would
be to accommodate the constraining autopkg tests.
| r-bioc-bioccheck is failing an explicit version check.
I think that one is expected / designed to notice that R is no longer the 4.4
that BioC 3.20 (of that package build) was aimed for as it is the very
package for BioC specific checks. On the other hand it loads just fine and
behaves:
> getRversion()
[1] ‘4.5.0’
> library(BiocCheck)
> search()
[1] ".GlobalEnv" "package:BiocCheck" "package:stats"
[4] "package:graphics" "package:grDevices" "package:datasets"
[7] "package:utils" "package:methods" "Autoloads"
[10] "package:base"
>
[ FWIW I also maintain (in the sense of build, distribute and look after)
essentially all 23k CRAN packages for all three Ubuntu LTSs, along with about
450 BioC packages. They all work reliably. I am still at BioC 3.20 there but
use R 4.5.0 as it is available. (The repo for these CRAN binaries is
frequently use along with the CRAN-mirrored repo of the current.) A fair
number of people rely on this for CI and other regularly scheduled jobs and
builds. As an example we had over 130k downloads yesterday, and generally
avergage about 500k/week these days. These package _work_ reliably if you
keep them current as CRAN does. See https://eddelbuettel.github.io/r2u ]
So there is no reason to believe that, say, IRange from BioC does not work
under R 4.5.0 even though it may come from the 3.20 believe. Hence, I do not
agree with the overall sentiment Charles expressed that we cannot release
this. It works, we can, and we have in the past.
And once the trixie release is out of the way BioC packages can update to
3.21 at their pace.
Cheers, Dirk
--
dirk.eddelbuettel.com | @eddelbuettel | edd@debian.org
Reply to: