[Rd] binary R packages for GNU/Linux

[Carl Boettiger]

Great discussion.

Just to note another example I don't think was mentioned -- The r-universe
project also builds binaries for Linux (Ubuntu latest)
https://docs.r-universe.dev/install/binaries.html (as well as other targets
including wasm).  It also provides binaries for Bioconductor and packages
on any git-based version control platform (e.g. GitHub).

R Universe is open source and a top-level project of the R Consortium.

Cheers,

Carl

---
Carl Boettiger
http://carlboettiger.info/


On Mon, Feb 10, 2025 at 5:30 AM Iñaki Ucar <iucar using fedoraproject.org> wrote:

> On Mon, 10 Feb 2025 at 14:09, Dirk Eddelbuettel <edd using 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 using debian.org
> >
> > ______________________________________________
> > R-devel using r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
> >
>
>
> --
> Iñaki Úcar
>
> ______________________________________________
> R-devel using r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

	[[alternative HTML version deleted]]