Planning to remove team-based R packages from 32-bit and big-endian architectures.

[Charles Plessy]

Hi all,

let's be realistic, the r-cran-* packages team-maintained by me and
others are not in a good shape. And given their complex net of
cross-dependencies, there is the risk of removing a large number of them
from Trixie before the release.

When I check the UDD maintainer dasboard to set my priorities, I am
distracted by issues related to the i386 and s390x platforms. For the
first, I am not convinced that we have users that need us to ship
r-cran-* packages in Trixie. For s390x, well, the popcon score is just
10


I do not believe that we will be able to fix everything on time, and I
want to move the less important issues out of the way. We have a script
(routine-update) that clones the source package repo from Salsa, updates
debian/control, builds the package, prepares a source-only upload and a
command to push the changes to Salsa. It has a --64 option that injects
architecture-is-64-bit in the build depends and I will add a
--little-endian one that will inject architecture-is-little-endian.

After uploading the changes, I will then ask the FTP team to remove the
team-maintained r-cran-* packages and all their reverse-dependencies
from the excluded architectures. I have added a DD list that tries to
predict the potentially affected packages. Please note that there are
false positives, as I generated it with dak rm -Rn r-base for
simplicity, but I am not proposing to touch r-base or the r-cran
packages managed by Dirk. The vast majority of the affected
dependencies are maintained by the Debian Med and Debian Science lists,
which I have CCed.

If you need one of the team-maintained r-cran-* packages on a 32-bit or
on a big endian architectures, which are not supported upstream, please
contact me on the debian-r list and let's see how we can share the
workload. Otherwise I will start the process next week, assuming silent
approval. The alternative is to lose a lot of r-cran-* packages from
amd64 as well.

Have a nice day,

Charles

[Simon McVittie]

Post by Charles Plessy
If you need one of the team-maintained r-cran-* packages on a 32-bit or
on a big endian architectures, which are not supported upstream, please
contact me on the debian-r list and let's see how we can share the
workload.

It might be best to re-send this to debian-arm (representing the two
32-bit release architectures with a porter mailing list) and debian-s390
(representing the only big-endian release architecture). Possibly also
debian-powerpc, although the big-endian versions of that are -ports
anyway.

(I don't expect that you will realistically get contributions from those
architectures, but it seems polite to let them know.)

smcv

[Paul Gevers]

Hi,

Post by Charles Plessy
If you need one of the team-maintained r-cran-* packages on a 32-bit or
on a big endian architectures, which are not supported upstream, please
contact me on the debian-r list and let's see how we can share the
workload.  Otherwise I will start the process next week, assuming silent
approval.  The alternative is to lose a lot of r-cran-* packages from
amd64 as well.

I haven't checked why they are there, but there are several packages in
the key package set [1]. I would be good to check beforehand what
happens if they are removed on those architectures. I think it's best to
assume for now that you can't remove them at this stage of the release.

Paul

[1] https://udd.debian.org/cgi-bin/key_packages.yaml.cgi

[Dirk Eddelbuettel]

On 16 April 2025 at 18:31, Paul Gevers wrote:
| I haven't checked why they are there, but there are several packages in
| the key package set [1]. I would be good to check beforehand what
| happens if they are removed on those architectures. I think it's best to
| assume for now that you can't remove them at this stage of the release.
|
| [1] https://udd.debian.org/cgi-bin/key_packages.yaml.cgi

That appears to be a different set of packages. It is comprised entirely of
packages that the meta package "r-recommended" depends upon. [ The R 'engine'
is provided by package "r-base-core" which can run on its own, the wider
package "r-base" also depends on "r-recommended" bringing these in. It is a
set of packages commonly used with R and curatedby upstream, that is by the
upstream R Core team. ] These packages are all maintained by me, and they
build fine under i386 etc. So no issue there as far as I can tell.

Cheers, Dirk

[Paul Gevers]

Hi Dirk,

Post by Dirk Eddelbuettel
| [1] https://udd.debian.org/cgi-bin/key_packages.yaml.cgi
That appears to be a different set of packages.

The packages spotted in the original list, I assume you're talking about
all of them except maybe cantor and vtk9?
boot: r-recommended depends r-cran-boot
cantor: kdeedu depends cantor
cluster: r-recommended depends r-cran-cluster
codetools: r-recommended depends r-cran-codetools
dh-r: boot build-depends dh-r
foreign: r-recommended depends r-cran-foreign
kernsmooth: r-recommended depends r-cran-kernsmooth
lattice: r-recommended depends r-cran-lattice
mgcv: r-recommended depends r-cran-mgcv
nlme: r-recommended depends r-cran-nlme
r-cran-class: r-recommended depends r-cran-class
r-cran-mass: r-recommended depends r-cran-mass
r-cran-nnet: r-recommended depends r-cran-nnet
r-cran-spatial: r-recommended depends r-cran-spatial
rmatrix: r-recommended depends r-cran-matrix
rpart: r-recommended depends r-cran-rpart
survival: r-recommended depends r-cran-survival
vtk9: opencv build-depends libvtk9-dev

Paul

[Dirk Eddelbuettel]

On 16 April 2025 at 19:24, Paul Gevers wrote:
| Hi Dirk,
|
| On 16-04-2025 18:55, Dirk Eddelbuettel wrote:
| > | [1] https://udd.debian.org/cgi-bin/key_packages.yaml.cgi
| >
| > That appears to be a different set of packages.
|
|
| The packages spotted in the original list, I assume you're talking about
| all of them except maybe cantor and vtk9?
| boot: r-recommended depends r-cran-boot
| cantor: kdeedu depends cantor
| cluster: r-recommended depends r-cran-cluster
| codetools: r-recommended depends r-cran-codetools
| dh-r: boot build-depends dh-r
| foreign: r-recommended depends r-cran-foreign
| kernsmooth: r-recommended depends r-cran-kernsmooth
| lattice: r-recommended depends r-cran-lattice
| mgcv: r-recommended depends r-cran-mgcv
| nlme: r-recommended depends r-cran-nlme
| r-cran-class: r-recommended depends r-cran-class
| r-cran-mass: r-recommended depends r-cran-mass
| r-cran-nnet: r-recommended depends r-cran-nnet
| r-cran-spatial: r-recommended depends r-cran-spatial
| rmatrix: r-recommended depends r-cran-matrix
| rpart: r-recommended depends r-cran-rpart
| survival: r-recommended depends r-cran-survival
| vtk9: opencv build-depends libvtk9-dev

Corret. Also, dh-r is only needed at build-time.

Dirk