Skip to content

[Bioc-devel] libRblas and libRlapack are broken dependencies for packages in R 3.1.0 on Fedora 20

4 messages · E N, Martin Morgan, M. Edward (Ed) Borasky

E N
#
Hi,

Let's me quote Ed Borasky <https://support.rstudio.com/hc/communities/public/questions/201046993-Library-dependency-issue-on-Fedora-20->: "When Fedora 20 migrated from R 3.0.2 to R 3.1.0, they switched from using the BLAS and LAPACK shipped with R to the BLAS and LAPACK from Fedora." Tom Callaway, R packager for Fedora, explained that here: <https://bugzilla.redhat.com/show_bug.cgi?id=1074975#c16>

That causes packages depending on libRblas or/and libRlapack to fail installation on Fedora 20 systems running R version 3.1.0. I tried to upgrade some packages to BioConductor 2.14 and all those having those libraries in dependencies failed the upgrade. Platform: x86_64-redhat-linux-gnu (64-bit). The failing packages are:

ChIPseqR, edgeR, IdMappingAnalysis, preprocessCore, RamiGO, RcppArmadillo, affy, DESeq2, DiffBind, oligo, ArrayExpress, gcrma, panp, ReportingTools, vsn, affycoretools, bgx, Ringo, simpleaffy, tilingArray, AgiMicroRna.

Is there any way to solve that issue upstream (R-Core), or will Fedora 20 users have to find workarounds themselves ?

Regards,
Eric.
#
On 05/06/2014 04:30 AM, E N wrote:
Let's focus on preprocessCore, which does not have any additional dependencies.

Also, I assume you mean that you are using R that comes with the fedora package 
manager, rather than the R that is redistributed by Rstudio.

If you could provide the output of

   R CMD config BLAS_LIBS

and the full output of

   R -e "library(BiocInstaller); biocLite('preprocessCore')"

again using the R that is installed with the fedora package manager, then that 
would help to understand your problem.

If your problem is only with the version of R distributed by Rstudio, then as I 
understand it the solution is in the hands of Rstudio, and I am sure they will 
respond promptly.

Martin

  
    
6 days later
#
E N <gifi2007 <at> hotmail.com> writes:
I'm also active on the Fedora Bugzilla for this issue:
https://bugzilla.redhat.com/show_bug.cgi?id=1074975

Here's a bit more detail. I don't know the exact process, but when a 
package is updated, like R 3.0.2 to 3.1.0, a Fedora packager takes an
existing source package, updates the pointers to the source and runs
through all the automated building and testing processes. Once that's
complete the package makes it into testing repositories and eventually
into the update repositories.

I discovered 3.1 was in Fedora's 'updates-testing' repository and
discovered the RStudio dependency conflict. Then after this reply from
the Fedora packager 

https://bugzilla.redhat.com/show_bug.cgi?id=1074975#c16
I posted the issue on the RStudio forum.

Meanwhile, it turns out that other packages besides RStudio and
BioConductor ones also seem to depend on libRblas or libRlapack. I don't
have a complete list. *And* it looks like R 3.1.0 has been pulled from
the Fedora updates-testing repository!

This will all sort itself out eventually, but meanwhile, if you're on
Fedora you're stuck with R 3.0.2 - I had to rebuilt two systems' worth of
R packages over the weekend when 3.1.0 vanished. :-(
#
1. It looks like R 3.1.0 is back in the Fedora updates-testing
repository. I just installed it and re-ran my install scripts.
2. A fair number of library packages appear to have been built around
the libRblas or libRlapack library. The ones I have had to re-install
so far are:

    'robustbase',
    'slam',
    'quadprog',
    'RcppEigen',
    'gnm',
    'ape',
    'igraph',
    'tseries',
    'fracdiff',
    'forecast',

and there are probably others - these are just the ones that crashed
while being test-loaded during *other* installs!

To be on the safe side I'd recommend re-installing all of your R
packages after you upgrade from R 3.0.2 to R 3.1.0. I'm going to post
a script to do that on the Fedora bugzilla entry as soon as I get a
chance to run it. And if you're using RStudio, I know the preview
release Version 0.98.836 (May 11th, 2014) works but I don't know if
they've backported the fix to their stable release.
On Mon, May 12, 2014 at 4:21 PM, M. Edward (Ed) Borasky <znmeb at znmeb.net> wrote: