Re: [R-sig-Fedora] R 4.0.0
On Fri, 15 May 2020 at 00:23, José Abílio Matos 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
___
R-SIG-Fedora mailing list
R-SIG-Fedora@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-fedora
Re: [R-sig-Fedora] R 4.0.0
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. :-)
Regards,
--
José Abílio
___
R-SIG-Fedora mailing list
R-SIG-Fedora@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-fedora
Re: [R-sig-Fedora] R 4.0.0
On Thu, 14 May 2020 at 21:41, José Abílio Matos wrote:
>
> On Monday, 11 May 2020 16.47.55 WEST Iñaki Ucar wrote:
> > AFAIK, there's this commitment only for patch versions. In fact, the
> > path for the personal library is:
> >
> > ~/R/x86_64-redhat-linux-gnu-library/./
> >
> > so, when you install a new minor version, you don't have any package
> > in your personal library. Most of the time, for many packages, it just
> > works if you copy the old packages into the new folder, but many times
> > things break and reinstallation is needed. And this may happen for
> > compiled packages, but also for non-compiled ones (e.g.: "Packages
> > defining S4 classes with the above S3/S4 classes as slots should be
> > reinstalled", in R 3.3.0).
> >
> > So maybe we should streamline mass rebuild of R packages, and do it
> > for all minor updates. The virtual provide you proposed will force us
> > to do that, and will prevent breakages and complaints.
>
> Something that I have been wondering for some time, previous to this thread,
> is why is not this the default also for system installation and not just for
> users installs.
>
> With this I mean to have the system directories to be respectively:
>
> %{__libdir}|%{__datadir}/R.
>
> Is this due to inertia or are there other reasons. That would naturally solve
> the need to rebuild for each minor release. The major point here is that would
> apply not only to our packages but also for others installed using R itself.
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?
--
Iñaki Úcar
___
R-SIG-Fedora mailing list
R-SIG-Fedora@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-fedora
Re: [R-sig-Fedora] R 4.0.0
On Monday, 11 May 2020 16.47.55 WEST Iñaki Ucar wrote:
> AFAIK, there's this commitment only for patch versions. In fact, the
> path for the personal library is:
>
> ~/R/x86_64-redhat-linux-gnu-library/./
>
> so, when you install a new minor version, you don't have any package
> in your personal library. Most of the time, for many packages, it just
> works if you copy the old packages into the new folder, but many times
> things break and reinstallation is needed. And this may happen for
> compiled packages, but also for non-compiled ones (e.g.: "Packages
> defining S4 classes with the above S3/S4 classes as slots should be
> reinstalled", in R 3.3.0).
>
> So maybe we should streamline mass rebuild of R packages, and do it
> for all minor updates. The virtual provide you proposed will force us
> to do that, and will prevent breakages and complaints.
Something that I have been wondering for some time, previous to this thread,
is why is not this the default also for system installation and not just for
users installs.
With this I mean to have the system directories to be respectively:
%{__libdir}|%{__datadir}/R.
Is this due to inertia or are there other reasons. That would naturally solve
the need to rebuild for each minor release. The major point here is that would
apply not only to our packages but also for others installed using R itself.
Best regards,
--
José Abílio
___
R-SIG-Fedora mailing list
R-SIG-Fedora@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-fedora
