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/<major>.<minor>/ > > 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<major>.<minor> 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
On Thu, 14 May 2020 at 21:41, Jos? Ab?lio Matos <jamatos at fc.up.pt> 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/<major>.<minor>/ > > > > 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<major>.<minor> > > 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
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