[R-pkg-team] Bug#1099927: r-cran-testthat does not actually break other packages

[Rebecca N. Palmer]

In addition to the 3 packages mentioned here, there are 11-13 other R 
packages that are broken only on less common architectures; these are 
*not* blocking r-cran-testthat / r-base, but need to be dealt with (e.g. 
by partial removal) at some point if we want to keep them on amd64.

https://bugs.debian.org/cgi-bin/pkgreport.cgi?which=maint&data=r-pkg-team%40alioth-lists.debian.net&archive=no&pend-exc=done&sev-inc=critical&sev-inc=grave&sev-inc=serious

On 23/04/2025 03:25, Charles Plessy wrote:
> Please let me know if there is a better way.

An approach I've often used in statsmodels is to ignore the test and 
print a warning on import/use, on the affected architecture(s): 
currently 
https://sources.debian.org/src/statsmodels/0.14.4%2Bdfsg-1/debian/patches/xfail_i386_ets.patch/ 
, previously also #968210 and #924036 but those have since been fixed.

This has the advantages that we only have to upload the directly 
affected packages, not upload their whole reverse dependency tree and 
wait for a partial removal to be processed, and that users can continue 
to use non-broken parts of the package, but the disadvantage that users 
might not see the warning if e.g. they're using the package in a script 
that runs headless.

> I want to solve that once for all by removing all 32-bit and big-endian
> architectures from the r-cran-* packages in Trixie.  I do not know a way that
> could be done without a mass update of all the packages,

If we are removing 32-bit packages, we still don't need to remove *all* 
of them to solve this bug, just the broken 3 and their reverse 
dependencies.  My usual script says these are r-cran-marginaleffects, 
r-cran-seurat, r-cran-sf, r-cran-spdep (all arch:any), r-cran-devtools 
(arch:all), but it only checks build and runtime depends/recommends, not 
autopkgtest depends.

(There is a separate proposal to remove all 32-bit R packages (except 
r-base + r-recommended) to reduce general maintenance burden, but during 
the freeze might not be the time for that.)

> but I still hope to do
> so in a week or two.

Given that the next stage of the freeze is 15 May (i.e. upload before 5 
May), and the risk that we don't get it right first time (or that it 
ends up blocked by some unrelated bug in one of this large set of 
packages), I'd also rather not need to wait that long.

> Also, I worry that any upload risks to
> delay the transition of r-base to Trixie.

If you're not sure what's allowed during the freeze, the place to ask is 
debian-release.

All the options we're considering involve uploading _something_ that 
needs to migrate with or before r-base and hence reset the 10-day clock.

Anything that involves partial removals also needs permission to ignore 
some arch:all packages (i.e. their reverse dependencies) becoming 
uninstallable on 32-bit architectures.  (By default, arch:all packages 
are expected to be installable there, 
https://salsa.debian.org/release-team/britney2/-/blob/master/etc/britney_nobreakall.conf?ref_type=heads#L30 
)