[R-sig-Fedora] R 4.0.0

[Iñaki Ucar]

On Sat, 16 May 2020 at 10:26, José Abílio Matos <jamatos using fc.up.pt> wrote:
>
> On Saturday, 16 May 2020 00.38.34 WEST Iñaki Ucar wrote:
> > Sorry, but I'm not sure I'm following you. How does having
> > /usr/lib64/R/library as system library prevent you from testing
> > r-devel?
>
> First the context, we are speaking of srpms.
>
> Use case: you want to test a pre-version of R before it is released and you
> want to do it using dnf while not having to de-install the current version,
> with all its libraries.
>
> Since the purpose is both to install and test both r-devel and the rpm
> packages the goal should be that the spec file should be as close as possible
> to the final spec file.
>
> What I am saying is that by experience it is easier to test and adapt a spec
> file if only a small number of conditionals are needed to use the current spec
> file.
> As far as I remember, from Miro's messages in fedora-devel, that is what is
> being done in the python packages.
> That is also what I have done for other packages, although not a language,
> like lyx.
>
> I hope that now it makes sense,

Makes sense. Then I think it's worthwhile paying attention at what
Dirk does for Debian. Debian's system path for R libraries is not
versioned, and neither it is the path for the r-devel package they
provide. Instead, r-devel stuff goes to /usr/local, and the binaries
are renamed as RD, RDscript. Finally, the R_LIBS_SITE variable in the
Renviron file takes the library under /usr/local first, then the
official system path /usr/lib/R/library.

Why is that? First, if you want to test r-devel, but you don't have
any packages, it makes little sense. But 90% of the time, the packages
compiled for the current version of R just work for r-devel, and
that's why /usr/lib/R/library is in their Renviron for r-devel. At
some point, a breaking change happens and some packages require
rebuilding. Then you can rebuild those few packages and place them
either under /usr/local or in your user dir, because both of them take
precedence, while continuing to reuse system libraries that still work
for r-devel.

So, wrapping up, there are 3 things that you need to do in the spec to
build r-devel as an RPM and test it: 1) redefine %{_libdir} and
%{_datadir} to include /local/; 2) modify the line that echoes
R_LIBS_SITE to the Renviron at your convenience (including or not the
official system path); 3) rename the executables to something like RD
and RDscript. And I think we could simply set up a Copr repo for this.
Maybe I'll do that.

That said, without any Copr repo, there are easier and faster ways to
test r-devel:

$ podman run --rm -it rocker/r-devel RD

and you're ready to go in a minute. :)

-- 
Iñaki Úcar