On Mon, 28 Apr 2025 at 09:11:51 +0900, Charles Plessy wrote:
on my side I have added a --64 option to the `routine-update` script (from the
same-named package) that adds a build-dependency on architecture-is-64-bits,
and plan to do the same for little-endian architectures.
This seems like a sufficiently common situation to encounter that the
ability to automate it is a useful thing, so thank you for doing this.
I wrote recently that I plan to restrict all the team-maintained r-cran-*
packages to 64-bit, little-endian. I have delayed that because of worries of
delaying migration of some packages with a mass upload, but...
Please note that we are about halfway through the soft freeze period for
trixie (2025-04-15 to 2024-05-15), and the release team writes:
new transitions, new versions of packages that are part of
(build-)essential or large/disruptive changes remain inappropriate
— https://release.debian.org/testing/freeze_policy.html#soft
I see from https://bugs.debian.org/release-critical/other/testing.html
that some of the r-bioc-* and r-cran-* family have been unable to
migrate to testing. How many of those bugs would be resolved by removing
their relevant packages from 32-bit and BE architectures, and how many
are orthogonal?
I am not a release team member, but I suspect that if removals are
necessary, at the current stage in the release process the release team
would likely prefer the R/CRAN team to remove only the packages that
genuinely do not work on 32-bit or BE, plus any packages that depend on
them and would be broken by their removal. For other removals that are not
necessary to resolve RC bugs, if it was up to me, I would defer them
until forky opens. (It is not up to me.)
I see that on #1099927, Rebecca already said some very similar things
about targeted removals being lower-risk and more appropriate at this
stage of the release process.
The usual way to research "what would happen if I removed..." is to log
in to the developer-accessible archive mirror machine
(coccia.debian.org, aka mirror.ftp-master.debian.org) and run commands
like for example:
# Architecture: all
dak rm -R -n r-cran-survminer
# Architecture: any
dak rm -R -n r-cran-sparr
At the time of writing, the results of those are that r-cran-survminer
could be removed without breaking anything else (it's a leaf package)
but r-cran-sparr could not be removed unless/until r-cran-kernelheaping was
also removed.
For your convenience, the r-bioc-* and r-cran-* RC bugs currently
relevant to testing:
* #1103217: FTBFS with newer compilers, fixed in sid, just needs migration
* #1103198: FTBFS with newer compilers, fixed in sid, just needs migration
* #1103227: FTBFS with newer compilers, fixed in sid, just needs migration
* #1103199: FTBFS with newer compilers, fixed in sid, just needs migration
* #1103200: FTBFS with newer compilers, fixed in sid, just needs migration
* #1102189: r-cran-argparser, autopkgtest regressions including 64-bit LE
* #1102589: r-cran-broom.helpers, see below, 32-bit autopkgtest already ignored
* #1102590: r-cran-fansi, see below
* #1100292: r-cran-fastcluster, build-time regressions including 64-bit LE
* #1104158: r-cran-testthat, is this fixed in 3.2.3-1?
* #1104159: r-cran-testthat, is this fixed in 3.2.3-1?
* #1104160: r-cran-testthat, seems i386 specific
* #1099927: r-cran-testthat, already has some useful analysis from Rebecca
* #1103228: FTBFS with newer compilers, fixed in sid, just needs migration
* #1102956: FTBFS with newer compilers, fixed in sid, just needs migration
* #1102345: seems fixed in sid, just needs migration
* #1103369: r-cran-webgestaltr, could be armhf specific
* #1102591: r-cran-units, seems arm{el,hf}-specific
#1104160 seems i386-specific and therefore could be helped by targeted
32-bit removals.
In #1102591 r-cran-units migration is blocked by autopkgtest regressions
on arm{el,hf}. At first glance this seems arm{el,hf}-specific and
therefore could be helped by targeted 32-bit removals.
#1103369 seems possibly armhf-specific and therefore could be helped by
targeted 32-bit removals, but I would suggest that a maintainer should
see whether the FTBFS is reproducible on 64-bit LE first (it doesn't
seem particularly 32-bit-specific).
In #1099927 in r-cran-testthat, migration is blocked by autopkgtest
regressions on 32-bit architectures (for which architecture-specific
removals might help) but also by an autopkgtest regression on riscv64
(which is 64-bit LE, so will be unaffected by your proposed removals).
#1104158 in r-cran-testthat refers to autopkgtest regressions. It seems
some of those might be fixed in 3.2.3-1? If this is the case, please
close the bug as fixed in the version in which it is fixed, so that the
release team can have some visibility into what it will take to get this
fixed in testing. Migration of r-cran-testthat/3.2.3-1 is blocked by
#1099927.
#1104159 in r-cran-testthat is similar to #1104158.
r-cran-broom.helpers #1102589 is blocked by #1102511 in r-cran-cards
(which would also require a freeze exception to get a new package into
trixie after the soft freeze deadline). It could be addressed by
removing r-cran-cards from i386, but it could also be addressed by
skipping one test using the patch that was already provided by Adrian
Bunk, which seems like a lower-risk change. Or r-cran-broom.helpers
could be rolled back to 1.20.0+really1.14.0 to avoid needing
r-cran-cards.
r-cran-fansi #1102590 seems to be failing all of its autopkgtests in
trixie on all architectures. Maybe one or more of its dependencies needs
to be raised to a higher version? Or maybe it should be rolled back to
1.0.6+really1.0.5 as a lower risk change at this stage. I don't see how
architecture-specific removals would help here.
#1102189, #1100292 seem like they would be a problem even if only amd64
was supported, so architecture-specific removals seem unlikely to help
here.
I would like to ask you "what about the architecture-independant packages"?
They will be built on amd64 and be available for the excluded architectures.
Is there a risk that a mixed dependency chain of architecture-specific and
architecture-independant packages which are all already in Trixie but will
disappear from some architectures in Sid will create a mess and therefore be
not able to migrate?
I would have expected that the R/CRAN team will know better than anyone
else how frequent this situation is, and therefore be able to assess the
risk more accurately than anyone else.
If you have this dependency chain:
r-cran-archall -> r-cran-archany -> other dependencies
then I believe the rule is that for either r-cran-archall or
r-cran-archany to be allowed to migrate, the installability of
r-cran-archall must not regress on amd64 or arm64. (Reference:
NOBREAKALL_ARCHES in https://release.debian.org/britney/britney.conf)
But if you have
larger-archany-package -> r-cran-archany -> ...
or
larger-archany-package -> r-cran-archall -> r-cran-archany -> ...
then larger-archany-package would need to be removed from the affected
architectures too, otherwise its installability would regress on the
affected architectures, which the migration scripts generally don't allow.
smcv
(not a release team member)
