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
