[R-sig-Fedora] R 4.0.0

[Iñaki Ucar]

On Fri, 15 May 2020 at 00:23, José Abílio Matos <jamatos using fc.up.pt> wrote:
>
> On Thursday, 14 May 2020 21.30.13 WEST Iñaki Ucar wrote:
> > Mmmh... but then you have to change that in the packages' SPEC and
> > rebuild them anyway when you update R. So... what's the advantage of
> > this?
>
> We already have other examples of how to do this with less steps. :-)
>
> Create macros like
>
> %{r_sitearch}
> %{r_sitelib}
>
> that expand with the R version being used and place them in R-rpm-macros and
> change all the R srpms to use them. We can also contribute changes to srpm
> generators like https://pagure.io/r2spec.
>
> This is a one-time change.
>
> Then when a new R version shows up it is enough to bump the release and
> rebuild the package. With the added advantage that all the cobwebs and dust
> are cleaned. :-)
>
> Another advantage is that the boilerplate code required to create a srpm
> package decreases. :-)

But we still have to rebuild the packages anyway, and this setup
doesn't force us to actually rebuild them, nor the user to update
them. So a user could end up with R major.minor and a bunch of
packages installed in some major.minor-1 path that are just junk. Or
the other way around: a bunch of packages updated under major.minor+1
with a previous version of R.

I mean, +1 to less boilerplate for packages, but changing the release
+ the ABI specification is not a big deal and solves those issues. For
me, having a path with full version specification only makes sense if
there is more than one version installed at the same time, like
Python.

-- 
Iñaki Úcar