Hmmm. That seems like a rather heavy dependency, given that I think we've only been forced to do rebuilds for everything as a result of 4.0.0 and 3.4.0. Does anyone know if upstream has any sort of commitment to ABI here that we could depend on (e.g. only breaking on major versions, never minor) ? Tom On Sat, May 9, 2020 at 5:32 AM I?aki Ucar <iucar at fedoraproject.org> wrote:> On Sat, 9 May 2020 at 05:46, Tom Callaway <tcallawa at redhat.com> wrote: > > > > Thinking out loud here... do we want to have some macro magic to embed a > > dependency on an R(ABI) provides? Where R 4.0.0 would provide R(ABI) = 4 > > and all R packages built against it would pick up Requires: R(ABI) = 4 ? > > Note that recompilation is sometimes required too for minor version > changes, so the virtual provides should include the minor version to > be in the safe side. > > > I don't suppose we need it, since the likelihood of someone installing R > > module packages but not updating R is low, but I wanted to throw it out > > there. > > Or updating R and not updating R packages. Even if the chances are > low, I think it's a cheap thing to add and would make the installation > more robust to this kind of issue. > > -- > I?aki ?car > > _______________________________________________ > R-SIG-Fedora mailing list > R-SIG-Fedora at r-project.org > https://stat.ethz.ch/mailman/listinfo/r-sig-fedora > >[[alternative HTML version deleted]]
On Mon, 11 May 2020 at 16:29, Tom Callaway <tcallawa at redhat.com> wrote:> > Hmmm. That seems like a rather heavy dependency, given that I think we've > only been forced to do rebuilds for everything as a result of 4.0.0 and > 3.4.0.That's just coincidence, because if you browse old NEWS, you can see "packages [doing this or that] need to be re(-)installed" here and there if most minor versions: maybe there wasn't any of such packages in Fedora, maybe a mass rebuild or an update fixed the issue before anyone noticed... It's just that we don't have any mechanism to detect that unless a user complains.> Does anyone know if upstream has any sort of commitment to ABI here that we > could depend on (e.g. only breaking on major versions, never minor) ?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. -- I?aki ?car
Okay, I'm convinced. https://github.com/rpm-software-management/R-rpm-macros/pull/1 Thanks, Tom On Mon, May 11, 2020 at 11:48 AM I?aki Ucar <iucar at fedoraproject.org> wrote:> On Mon, 11 May 2020 at 16:29, Tom Callaway <tcallawa at redhat.com> wrote: > > > > Hmmm. That seems like a rather heavy dependency, given that I think we've > > only been forced to do rebuilds for everything as a result of 4.0.0 and > > 3.4.0. > > That's just coincidence, because if you browse old NEWS, you can see > "packages [doing this or that] need to be re(-)installed" here and > there if most minor versions: maybe there wasn't any of such packages > in Fedora, maybe a mass rebuild or an update fixed the issue before > anyone noticed... It's just that we don't have any mechanism to detect > that unless a user complains. > > > Does anyone know if upstream has any sort of commitment to ABI here that > we > > could depend on (e.g. only breaking on major versions, never minor) ? > > 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. > > -- > I?aki ?car > >[[alternative HTML version deleted]]
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