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