Support for the ARM64 system architecture

[SamThilmany]

The rocker/r2u containers seem to be fixed to the AMD64 architecture, as the usual automatic selection of the correct underlying system architecture does not work. Unfortunately, this means that the containers on Apple M-chips are quite slow, as they are based on the ARM64 architecture and the entire code has to be compiled with Rosetta.

Are there plans to support ARM in the future?

[eddelbuettel]

Well "if you provide 20k binaries, maybe I can wrap them" and provide .deb packages. As documented, currently we get x86_64 binaries for approximately 98 or 99 per cent of CRAN from p3m, and I build the remaining ones from source as I do for all the BioConductor packages I cover.

I do this a side project, and I don't have hardware with an M chip. (Also, do you expect to run macOS on it yet look at an apt-based binary repo? Do the Ubuntu amd64 binaries run in Docker on these chips?) So I think I may have to pass this task on to someone else who actually has that itch to scratch.

I happen to work (a lot / mostly) on Ubuntu so r2u helps me there, and it also happens to be used a lot in CI, on cloud, by other people so it all makes sense the way it is currently. For another scope, I guess we'd need another plan.

[eddelbuettel]

Just to confirm: Can you run rocker/r-base in amd64 in Docker without Rosetta?

I.e. is there a sufficient base of R itself that we could work on if we had the resources / if another volunteers wanted to shadow r2u with an amd64 variant for all the packages not in Ubuntu? (You get about ~1k as r-cran-*, not always current, and obviously not as comprehensive as the ~6k at c2d4u or the 22k at r2u.)

[SamThilmany]

I am well aware that this is a lot of work, but I don't have enough expertise in this area to know how much may already exist as binary files or how much effort it takes to build them from the source files. Due to this lack of knowledge on my part, I merely asked nicely if there were any plans for the future and made no demands whatsoever.

To your questions:

1) I don't really understand what you mean by whether I expect to run macOS "on it". I use an Apple computer and thus am using the ARM chip architecture. Docker allows me to create project-specific containers that contain the tools I need for the specific use case. After all, that is the actual purpose of Docker.

2) No, rocker/r-base will also be built as an AMD64 image. However, a container with Ubuntu:Jammy and apt-get install r-base results in an ARM64 image, so in principle, there should be no objection to this, purely from an R perspective. I also have several containers with R, all of which work without any problems, even with all packages, including BioConductor. The only reason why I came across r2u in the first place is that it is easier and faster to set up containers.

---

**Dockerfile that will build an ARM64 image***

FROM ubuntu:jammy

RUN apt-get update && \
    apt-get install -y --no-install-recommends \
    r-base

[eddelbuettel]

Ok, so then this is merely lacking a driven volunteer, possibly even you !, to create the 22k binaries (or 44k if you want to cover focal and jammy). The r2u code is public, and you are more than welcome to adapt it.

My needs are met by x86_64 so I will try to continue to provide support for that architecture. Upgrading to Ubuntu 24.04 when it comes out will be enough.

Support for other architecture is not on the 'roadmap'. In fact, there is not 'roadmap'. It's just a part-time project of one guy who also looks after 180 Debian packages he maintains, at least a half-dozen Rocker container builds, some 60+ CRAN packages and more. There is a limit to how much I alone can do, and this appears to be on the other side of the line. Truly sorry. But Open Source is itch driven so maybe one day someone reads this and may pick up this torch.

Until then I will close this as 'not planned'. Sorry.

[eddelbuettel]

I'll adjust the website to

1. make it more clear this is currently x86_64 only
2. if someone has interest and resources (storage, cpu hours, ...) to support another architecture to get in touch