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 <iu...@fedoraproject.org> wrote: > On Mon, 10 Feb 2025 at 14:09, Dirk Eddelbuettel <e...@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 | e...@debian.org > > > > ______________________________________________ > > R-devel@r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/r-devel > > > > > -- > Iñaki Úcar > > ______________________________________________ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > [[alternative HTML version deleted]] ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
