R devel - Feb 2025 - binary R packages for GNU/Linux

On Mon, Feb 10, 2025 at 9:48?PM Simon Urbanek
<simon.urbanek at r-project.org> wrote:
>
>
> > On Feb 11, 2025, at 5:23 AM, Dirk Eddelbuettel <edd at
debian.org> wrote:
> >
> >
> > On 10 February 2025 at 07:35, Carl Boettiger wrote:
> > | 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).
> >
> > Yes ... but these are 'naked' binaries as created by 'R
CMD INSTALL --build'
> > but without system integration (and as such mirror what p3m.dev does).
This
> > has its merits (it is simpler, can cover more OS variants) but it is
also
> > more limited.
> >
> > What we (ie Detlef, Inaki, myself) myself do for the distros is
fundamentally
> > different. Both are merits, both can coexist, but I like the added
'oomph'
> > you get by integrating properly with the distribution you deploy on. 
Ubuntu
> > is a pretty useful base case.
> >
>
>
> In case it wasn't clear - precisely this was my point, and I was
counting on all those doing the hard work already like Dirk to speak up (thanks,
Dirk and I?aki). I'm not convinced that "naked" binaries are that
useful, so just creating a new subdirectory isn't a solution IMHO. It works
for some cases, but not in general - many can build their specific binaries, but
it doesn't mean they work for others.
The "naked binaries" are widely used, and therefore probably useful to
many folks, me included. Some standardisation on paths would be
incredibly useful, even if CRAN would not offer such binaries, other
repositories could.

Note that Dirks apt packages are literally repackaged binaries form
p3m, for convenience of ubuntu (root) users. As Dirk noted, some
people prefer installing binaries via apt rather than
install.packages(), which is all fine, but methods both have pros and
cons. However, any arguments against p3m based on TOS or compatibility
will extend to the repackaged apt binaries, so I don't think that
argument holds.

On 10 February 2025 at 23:19, Jeroen Ooms wrote:
| The "naked binaries" are widely used, and therefore probably useful
to
| many folks, me included. Some standardisation on paths would be
| incredibly useful, even if CRAN would not offer such binaries, other
| repositories could.

Sure, but naked binaries can (and do) break more often i.e. real example from
just last week in another project p3m served a stringr dependency via a
stringi binary with a wrong libicu* outside of the particular release,
breaking.  That simply cannot and hence will not happen at r2u.

But choice is good. If people want to manually manage their system
dependencies they surely, they can also outsource it to another layer. As you
say, all trade-offs and if you are happy with naked binaries more power to
you. I prefer the proper integration and that's what I built. 

Dirk

-- 
dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org