binary R packages for GNU/Linux

On Mon, 10 Feb 2025 at 14:09, Dirk Eddelbuettel <edd at debian.org> wrote:

On 10 February 2025 at 11:00, Tobias Verbeke wrote:
| Another argument to demonstrate the feasibility is the r2u project
| (https://github.com/eddelbuettel/r2u). It offers CRAN as Ubuntu

Binaries, but

| in order to build these Ubuntu Binaries it actually makes use of the

binary R

| packages built by PPM. Quoting from

https://eddelbuettel.github.io/r2u/: "For

| the CRAN binaries we  either repackage P3M/RSPM/PPM builds (where
| available) or build natively." They cover all CRAN packages. The usage

of PPM

| as a source is, of course, a weakness (in the grand scheme of things),

but

| the point here is about the feasibility of building the packages in a
| portable way per version of a particular distribution, architecture

etc.

As you brought this up, allow me to clarify: The re-use (where possible)

is

simply a shortcut "where possible".  Each day when I cover updated

packages,

I hit maybe 5 per cent of packages where for reasons I still cannot

decipher

p3m.dev does not have a binary, so I build those 5 per cent from source.
Similarly for the approx 450 BioConductor packages all builds are from
source.

Rebuilding everything from source "just because we want to" is entirely
possible but as it is my time waiting for binaries I currently do not

force

full rebuilds but I easily could. Also note that about 22% of packages
contain native code, leaving 78% which are not. Re-use is even simpler

there

as these 78% as they contain only (portable) R processing. So if we

wanted to

compile all native packages for Ubuntu, we could. It is a resourcing

issue

that has not yet been a prioruty for me. Inaki does it for Fedora, Detlef
does it for OpenSUSE.

And for completeness, [1] is where we painstakingly* maintain a list
of system dependencies, [2] is where the daily magic happens for
keeping track of CRAN, and [3] performs the heavy-lifting and
publishes an RPM repository with the result.

[1] https://github.com/cran4linux/sysreqs
[2] https://github.com/cran4linux/cran2copr
[3] https://copr.fedorainfracloud.org/coprs/iucar/cran

*Because, you know, SystemRequirements.

The more important point of these package is the full system

integration. You

do get _all_ binary dependencies declared, exactly as a

distribution-native

package (of which Debian/Ubuntu have a bit over 1k) would. Guaranteed.
Reliably. Fast. That is a big step up for large deployments, for

testing, for

less experienced users.

So thanks for starting a discussion around this as 'we' as a community

are

falling a bit short here.

Indeed, thank you, Tobias.

One open question is if we could pull something off
that works like the Python wheels and offers cross-distro builds, ideally
without static linking. Your "CRAN libraries" added to the ld.so path

may do

this. I do not know how feasible / involved this would be so so far I
concentrated on doing something simpler -- but feasible and reliable by
working exactly as the distribution packages work.

It would be perfectly feasible to maintain sync'ed builds (in terms of
version) of system dependencies at CRAN-provided (RPM, APT...)
repositories as compat packages for various distributions, then all
packages could be built once and shipped everywhere (i.e. cross-distro
builds). Collaterally, this would increase reproducibility of package
checks to a certain extent.

I offered my help in these matters in the past, but was kindly
declined. That hand remains extended.

Best,
I?aki

All that said, thanks for the starting this discussion!

Cheers, Dirk

--
dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org

--
I?aki ?car