Dear Release team,
as you may have seen, we are struggling with a lot of r-cran* packages for the Trixie release.
Core issues are:
- Breakage on unsupported architectures upstream,
- Autopkgtest failures on amd64 / arm64 that we do not know how to troubleshoot
efficiently (other than turning off tests),
- R 4.5 transition.
Every single point in that list is already enough to worry that we will not make it in time for the freeze.
There are very little returns and incentives to support r-cran-* packages on archtectures that are not supported upstream. Indeed, in a lot of cases the "support" we give is just to turn off tests to hide the fact that the packages do not work on non-mainstream (amd64, arm64) architectures, to ease migration.
At least on my side, unsupported architecture breakages blur the radar for finding priorities on the two other points, and add some convolutions to some of the fixes. I think that everything would be simpler if the packages would simply not be present on these architectures. Please note again that we are already unable to promise that the packages are really working there, because we sometimes turn off tests as a fix. Also in at least some of the architectures like i386 I think that it is fair to say that it is unlikely that somebody actually needs these packages to be present and functional in Trixie.
The dependency tree of the r-cran-* (and r-bioc-*) packages maintained by the Debian R packaging team is mostly self-contained, with the exception of packages maintained by the Debian Med and the Debian Science teams, which
are actually the motivation for packaging some of these r-cran-* packages.
Earlier I asked debian-devel, Debian Med, Debian Science and Debian R teams if it would be fine to remove the packages and their reverse dependencies from
the unsupported architectures, and I did not receive major objections.
There are a few r-cran-* packages maintained by Dirk, which are more at the core of the CRAN dependency graph. I am not asking to remove these. The r-base package is available on all release architectures and provides the
tools needed to install CRAN pakcages directly from CRAN.
The mass removal seems to necessitate a mass upload; I am committed to do it if necessary (and eventually) but I was wondering if there would be a possible shortcut with the help of the Release team, for just removing the packages from Trixie at the moment, because I expect that a mass upload can cause migration delays at a time where it really matters.
Can you remove the r-cran-* packages and all their reverse-Depends from
Trixie on all the 32-bit and big-endian architectures?
Have a nice day,
Charles
--
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Debian Med packaging team
http://www.debian.org/devel/debian-med Tooting from home
https://framapiaf.org/@charles_plessy
- You do not have my permission to use this email to train an AI -
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)