Standardizing the URL format for Linux binary packages

[jeroen]

On Linux install.packages() has no default path where it looks for binary packages. Right now we get:

options(pkgType='both')
install.packages("jsonlite")
# Error in install.packages("jsonlite") :
#  type == "both" can only be used on Windows or a CRAN build for macOS

I think this is historically because CRAN does not provide binary packages on Linux, but these days they are widely in use through e.g. posit and r-universe.

• https://packagemanager.posit.co/cran/__linux__/centos8/latest/src/contrib/jsonlite_1.8.7.tar.gz?r_version=4.3&arch=x86_64
• https://packagemanager.posit.co/cran/__linux__/jammy/latest/src/contrib/jsonlite_1.8.7.tar.gz?r_version=4.3&arch=x86_64
• https://packagemanager.posit.co/cran/__linux__/bookworm/latest/src/contrib/jsonlite_1.8.7.tar.gz?r_version=4.3&arch=x86_64

Hosts of linux binaries have to use a hack where Linux binary packages are served instead of source packages in directory under src/contrib and letting users opt-in by setting a particular options(HTTPUserAgent), which is a bit painful.

A more elegant solution would be to generalizing the URL format used on MacOS to other distros. On MacOS this format is used:

• https://cran.r-project.org/bin/macosx/big-sur-x86_64/contrib/4.3/
• https://cran.r-project.org/bin/macosx/big-sur-arm64/contrib/4.3/

I think this format can probably be used for any os / distro / arch combination, for example:

https://cran.r-project.org/bin/linux/jammy-x86_64/contrib/4.3/
https://cran.r-project.org/bin/linux/centos8-arm64/contrib/4.3/
https://cran.r-project.org/bin/linux/bookworm-arm64/contrib/4.3/

One tricky part is determining the proper distro slug (e.g. jammy or centos8), I suppose that should be another option() to derive the full URL.

Would be interested to hear opinions from @s-u @kurthornik @kalibera and Uwe.

[aitap]

R already parses /etc/os-release in sessionInfo(). Either that or lsb_release -s -i -r can be used to derive the distro URL component. (On the other hand, distros distinguish between point releases, e.g. Debian 9.12 ≠ Debian 9.13, but don't change the codename (lsb_release -c) on such updates.)