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):
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
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.