From edd @end|ng |rom deb|@n@org  Mon Feb 10 14:08:45 2025
From: edd @end|ng |rom deb|@n@org (Dirk Eddelbuettel)
Date: Mon, 10 Feb 2025 07:08:45 -0600
Subject: [Rd] binary R packages for GNU/Linux
In-Reply-To: <01020194ef842fd9-d0ae4ebf-98bb-48ea-be9d-f72bff73eda8-000000@eu-west-1.amazonses.com>
References: <01020194ef1ddab7-7ce660cf-1bd2-4d56-9426-3d3930019d6a-000000@eu-west-1.amazonses.com>
 <45B7CFB4-A9F9-48EA-9B68-5CEA81B2F91D@R-project.org>
 <01020194ef842fd9-d0ae4ebf-98bb-48ea-be9d-f72bff73eda8-000000@eu-west-1.amazonses.com>
Message-ID: <26537.64093.228457.76824@rob.eddelbuettel.com>


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.

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. 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.

All that said, thanks for the starting this discussion!

Cheers, Dirk

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



[Rd] binary R packages for GNU/Linux
Dirk Eddelbuettel