This breaks down for many R packages, which build from source on Linux by default. Try, for example, the CRAN package
sodium (https://cran.r-project.org/web/packages/sodium/index.html). First of all, it won’t install because
libsodium isn’t on the default system. With a
sudo swupd search-file libsodium you can find the bundle that carries
libsodium and install it. But the package still won’t build.
On Debian, it’s still a two-step process - try to install the R
sodium package and it fails. However, the package developers were kind enough to tell you the name of the Debian package (and the Fedora / RHEL package) you need to install. It’s still a two-step process, but at the end you have the
sodium CRAN package on your system.
On Arch it’s a two-step process, unless you’ve already installed the Arch
sodium package because something else depends on it, in which case it just works. But since the R package developers didn’t do the kind thing for Arch users, you have to figure out which Arch package to install yourself.
My point is that you (and Red Hat and Debian) have forced the R package developer and the R package user to do extra work. Releasing packages as complete wholes, as the package developer designed them and like Gentoo and Arch and their derivatives do, lessens this work. It made sense when the
.RPM package systems were created - disks were small and bandwidth was low. 20 years of Moore’s Law have changed the tradeoff between hardware costs and programmer time.
It’s more work for Clear maintainers too - your release engineering process builds all the binary RPMs anyhow, but you have to decide which RPMs go in the main bundle and which ones go in a “devpkg” bundle. And in the case of R packages and the GIS stack, you’re missing some capabilities. So you’ll get bugs that you have to triage. And people will run R and GIS in containers that just work.