On 10 July 2023 at 19:43, Dirk Eddelbuettel wrote: | Someone simply didn't update our Debian package, so it lacks this change and | fingers point at r-base when the fault, if there is one, is to let our | package slip behind a compilation and code standard established at CRAN for | the R 4.3.0 relese in April. | | I still have hopes that we can let technical excellence rule and not require | blunt instruments such as forced recompilation. | | Because with slips like this, even forcing recompilation of over 1000+ | sources packages times 10+ architectures (for binary-any) will not help | against stale code, and hence mismatched expectations in the language engine | (r-base) and its client packages.
I should have double-checked. 1.22.1-1 is in unstable, so that is good, and hence works with R 4.3.[01]. So what tripped me up is the (known, and expected, if "you know") failure in the (hence not all that informative) autopkgtest of trying R 4.3.1 with the outdated maldiquant 1.22 (not 1.22.1). I am not versed well-enough in the mechanics of release details. If the only way to get r-base into testing consists of having a Breaks for r-cran-maldiquant (<< 1.22.1) then I guess that is what we need to do. Dirk -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
