On Thu, Jun 22, 2023 at 01:56:16PM +0200, Andreas Tille wrote: > If someone thinks we should keep 32bit support and apply the patch > suggested to r-base (which Dirk seems to be willing to) please speak > up soonish (in the next two weeks).
I think we should keep 32-bit. Some reasons I can think of are: 1. rstan has got a lot of reverse-build-deps and reverse-deps and those reversd-deps have further more of them. rstan is kind of an important package in that sense, and dropping 32-bit arch for this would mean filing arch specific rm bugs for a lot of R packages, and I'm quite un-happy with the amount of noise that it will potentially create. For instance: | $ reverse-depends r-cran-rstan | Reverse-Recommends | ================== | * r-cran-bayesplot | * r-cran-bayestestr | * r-cran-broom.mixed | * r-cran-mice [amd64 arm64 armel armhf i386 mips64el ppc64el s390x] | * r-cran-rstantools | | Reverse-Depends | =============== | * r-cran-brms | * r-cran-prophet [amd64 arm64 armel armhf i386 mips64el ppc64el s390x] | * r-cran-rstanarm [amd64 arm64 armel armhf i386 mips64el ppc64el s390x] | * r-cran-shinystan Oh, I see shinystan and stanarm, let's check for these... | $ reverse-depends r-cran-rstanarm -b | Reverse-Testsuite-Triggers | ========================== | * r-cran-bayesplot | * r-cran-broom.mixed | * r-cran-datawizard | * r-cran-ggeffects | * r-cran-insight | * r-cran-parameters | * r-cran-performance | * r-cran-projpred As you may see, the list will get long at some point. 2. We recently packages shiny-server, and there are people who would like to run it on a single board computer (like rpi). On a quick search I even managed to find a blog post about the same[1]. Now, these run on debian armhf and armel mostly, therefore having r-packages support it would be good. 3. Removing this package from 32-bit will increase quite a bit of entropy across many cran packages that we have with some of the packages supporting 32-bit and a bunch of packages that do not. I do not have a very strong opinion for keeping it, and if keeping 32-bit support is making your life un-necessarily and extremely hard, drop it by all means. But I do think we should consider keeping support when it is a possibility. I'd have without a second thought agreed to have dropped support for a debian-med team package had you asked, since most of those packages are leaf packages and supporting 32-bit is irrelevant for most bioinformatics cases, but I do not think I could say the same about R. Let me know what you think. [1]: https://andresrcs.rbind.io/2022/09/05/shiny_rstudio_server/ [2]: https://wiki.debian.org/RaspberryPi#Raspberry_Pi_3_.283.2C_3A.2B-.2C_3B.2B-.2C_Zero_2_W.29 -- Best, Nilesh
signature.asc
Description: PGP signature
