Description of problem: The upgrade from R-3.3.2-2.el6.x86_64 to R-3.3.2-3.el6.x86_64 includes a switch from external to internal blas library. However, as R's library directory is in ld.so's path, a symlink is generated: # ls -l /usr/lib64/R/lib/*blas* lrwxrwxrwx. 1 root root 11 14. Dez 08:48 /usr/lib64/R/lib/libopenblas.so.0 -> libRblas.so This can create problems with applications linked to libopenblas.so.0 which were meant to be linked to /usr/lib64/libopenblas.so.0: [root@nafhh-herafitter ~]# ldd xfitter |grep -i blas libopenblas.so.0 => /usr/lib64/R/lib/libopenblas.so.0 (0x000000324e800000) Version-Release number of selected component (if applicable): 3.3.2-3.el6 How reproducible: always Steps to Reproduce: 1. Install R-3.3.2-2.el6.x86_64 2. upgrade to R-3.3.2-3.el6.x86_64 3. run ldd on any program linked to libopenblas.so.0 Actual results: /usr/lib64/R/libopenblas.so.0 Expected results: /usr/lib64/libopenblas.so.0 Additional info: The symlink /usr/lib64/R/lib/libopenblas.so.0 is not automatically removed on upgrade or uninstallation of the R-core package.
Okay, so that is a relic of R-3.3.2-2.el6.x86_64. The libopenblas symlink was created because in that package, libRblas.so was a symlink directly to libopenblas.so.0. ldconfig made the additional /usr/lib64/R/lib/libopenblas.so.0 symlink. If you install just R-3.3.2-3.el6.x86_64 (not upgrade from -2), you should not generate that file. No one else should generate it going forward. You should be safe to simply remove /usr/lib64/R/lib/libopenblas.so.0 manually. I'm a bit reluctant to add a scriplet to remove that file, since technically, R didn't own it to start with, and it only got created when -2 was installed (and no one should be installing -2 anymore)... thus, I'm closing this WONTFIX.