Support from Amazon Linux 2023

[grantmcdermott]

Hi Inaki,

As you probably know/remember, AL2023 is the successor to AL2 (already supported by rspm) and is based on RHEL 9.

A few of us have tested compatibility directly with PPM's (RSPM's) RHEL 9 builds and, for the most part, everything seems to be working smoothly. (c.f. rstudio/r-builds#197 (comment))

I personally have tested on many packages now and the only sharp edges that I have encountered are related to missing runtime system dependencies for

• geospatial libraries like sf (c.f. [Package Request] - GDAL amazonlinux/amazon-linux-2023#129), and
• igraph (c.f. [Package Request] - glpk amazonlinux/amazon-linux-2023#733)

Given the centrality of these two libraries, I'm not sure if you'd prefer to wait and defer. But I wanted to put it on your radar all the same.

Thanks for considering (and for all the work that you do supporting R infra for Linux users).

• Follow up to Add support for CentOS/RHEL 9 and derivatives #12.
• Related to Amazon Linux 2023 target cran2copr#39

[Enchufa2]

Can you please try the branch feature/27?

[grantmcdermott]

Thanks.

I tried yesterday with the latest AL2023 Docker image and it mostly seems to work well for supported cases. For example, install.packages("magick") grabs the R binary (plus deps) from PPM and also pulls in the necessary system deps (ImageMagick-c++- , etc.). Once installed, the magick package works as expected. The same is true for other R packages that require (pre)compilation but no sysdeps, including fastverse, tidyverse, arrow, duckdb, and fixest.

However, I did hit a snag trying to install packages where the relevant system dep is missing. For example, install.packages("Rpostgres") fails with the following warning.

Last metadata expiration check: 0:07:33 ago on Tue Jun 18 00:40:21 2024.
No match for argument: */libpq.so.private13-5
Error: Unable to find a match: */libpq.so.private13-5

That's expected, but the real snag is that once I triggered this behaviour for a package with a (known) missing system dep, then I couldn't install any other packages with sysdeps thereafter; including packages that would install fine if switched the order by installing them first. (E.g. install.packages("magick") no longer works if it comes after the failed install.packages("RPostgres") command.) rspm seems to get stuck in a loop, where it repeats the same match error from the previous failed installation.

Thoughts?

Install script

pull amazonlinux:2023
docker run -it amazonlinux:2023 /bin/bash

# Some system libs
dnf install -y git tar libcurl-devel

# Which R version do we want?
R_VER="4.4.0"

# Download from Posit and add to our PATH
curl -O https://cdn.posit.co/r/rhel-9/pkgs/R-${R_VER}-1-1.x86_64.rpm
dnf install -y R-${R_VER}-1-1.x86_64.rpm
echo "export PATH=\$PATH:/opt/R/${R_VER}/bin" >> $HOME/.bashrc
source $HOME/.bashrc

# Clone and install rspm feature/27 branch
git clone --branch feature/27 --single-branch --depth 1 https://github.com/cran4linux/rspm.git
R CMD INSTALL rspm

# Open R and enable rspm
R
rspm::enable()

[Enchufa2]

I certainly did not take into account the case where some dependencies may be available and some others not. I'll revise the logic considering this.

[Enchufa2]

Ok, it seems to work here now, but please double check just in case with the latest commit in that branch. We try to install the unique set of dependencies first, preserving the previous behavior, but then, if this fails, we try package by package. You'll still see the error, as expected, but dependencies for e.g. magick should work.

[grantmcdermott]

Test and all seems to be working now from my side. Thanks!

[Enchufa2]

This will become v0.6.0 soon.

[Enchufa2]

On CRAN now.

[grantmcdermott]

Brilliant, thanks!