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 at fedoraproject.org>
wrote:
> 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
> >
> > ______________________________________________
> > R-devel at r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
> >
>
>
> --
> I?aki ?car
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
[[alternative HTML version deleted]]