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
On Fri, 15 May 2020 at 00:23, Jos? Ab?lio Matos <jamatos at 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
On Thursday, 14 May 2020 23.58.02 WEST I?aki Ucar wrote:> 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.Honestly my point here was for consistency with the user settings. If you have per version directories for users why not to do the same for the system?> 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.That would also be a nice side effect. :-) -- Jos? Ab?lio