Bugzilla (bugzilla.redhat.com) will be under maintenance for infrastructure upgrades and will not be unavailable on July 31st between 12:30 AM - 05:30 AM UTC. We appreciate your understanding and patience. You can follow status.redhat.com for details.
Bug 1805528 - R does not provide libRlapack.so() anymore
Summary: R does not provide libRlapack.so() anymore
Alias: None
Product: Fedora
Classification: Fedora
Component: R
Version: rawhide
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Tom "spot" Callaway
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2020-02-20 23:09 UTC by Fabio Valentini
Modified: 2020-03-17 20:40 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2020-03-17 20:40:17 UTC
Type: Bug

Attachments (Terms of Use)

Description Fabio Valentini 2020-02-20 23:09:09 UTC
It looks like this was dropped with the recent refactoring commit.

The following R packages have a dependency on libRlapack.so(){,(64bit)}, which is now broken:

- R-ape
- R-expm
- R-gss
- R-igraph
- R-msm
- R-preprocessCore
- R-qtl

Comment 1 Fabio Valentini 2020-02-23 21:26:45 UTC
I think this has now been resolved by rebuilding the packages. Thanks!

Comment 2 Elliott Sales de Andrade 2020-02-24 10:57:34 UTC
This is also in a buildroot override for stable releases. I don't think that this removal is consistent with our stable updates policy.

Also, according to koschei, switching math libraries may have broken a couple package test suites on aarch64

Comment 3 Tom "spot" Callaway 2020-02-25 13:59:36 UTC
The difficulty here is this: the use of the built-in mini lapack in R was not the intended behavior for any release targets except for those where there were known issues with openblas (or reference lapack/blas), specifically, RHEL <= 7. There is no good time to revert this change, but it does need to be done. It was causing CRAN modules to fail to build properly, when they detected libRlapack.so.

That said, if you feel strongly that this fix should not be done on Fedora 30/31, we can freeze R as is on those branches.

As far as the switch causing test fails on aarch64, there may be a legitimate openblas bug on aarch64, but it would have to be rather lapack specific (since Fedora was already replacing the R mini-blas with openblas everywhere).

Comment 4 Elliott Sales de Andrade 2020-02-25 21:37:22 UTC
Well, the problem with R is that it's also its own package manager, and users could install any of the above broken packages manually with `install.packages`. Then if they get this upgrade their existing installs will break. I don't know how badly CRAN modules fail to build, so I don't know what the trade off is there.

I expired the overrides until we can decide on this, but now Bodhi thinks they're mine (if you were looking for them.) It was only a couple of hours earlier that it would have been though, so I could dump all my builds before F32 Beta Freeze.

I can investigate the aarch64 stuff some time, and I'm not too concerned with that just yet.

Comment 5 Tom "spot" Callaway 2020-02-26 12:49:20 UTC
People will hit the "local packages now broken" issue when they upgrade to Fedora 32, but I suppose a certain amount of that is to be expected. I'm fine with freezing R for Fedora 30/31 (barring some security issue or severe bug that needs fixing).

I do think we need to push this update for EPEL-8 now, while that release is relatively young, even though it will hit the same issue you describe.

Comment 6 Elliott Sales de Andrade 2020-03-05 06:53:51 UTC
So those aarch64 things seem to have fixed themselves with 3.6.3 and/or openblas 0.3.9.

Comment 7 Fabio Valentini 2020-03-17 14:59:15 UTC
With the exception of R-igraph (which is FTBFS for other reasons), I think this has been resolved.
Feel free to close this bug if my assessment is correct :)

Comment 8 Tom "spot" Callaway 2020-03-17 20:40:17 UTC
Agreed. Now I'm just hoping R 4.0.0 doesn't require a mass rebuild, but I'm sure it will. :/

Note You need to log in before you can comment on or make changes to this bug.