[R-pkg-team] Bug#1037439: Opinions about removal of 32bit architecture for r-cran-rstan (Was: Bug#1037439: r-cran-rstan/armhf FTBFS with r-cran-bh 1.74)

Nilesh Patra nilesh at debian.org
Thu Jun 22 17:36:02 BST 2023


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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/r-pkg-team/attachments/20230622/4a2a75ed/attachment-0001.sig>


More information about the R-pkg-team mailing list