Description of problem: package: scalapack-mpich2-1.7.5-17.el6.1.i686 from epel unresolved deps: mpich2 libmpich.so.1.2 package: scalapack-mpich2-1.7.5-17.el6.1.x86_64 from epel unresolved deps: mpich2 libmpich.so.1.2()(64bit) mpich2 got obsoleted.
scalapack-2.0.2-5.el6.1 has been submitted as an update for Fedora EPEL 6. https://admin.fedoraproject.org/updates/scalapack-2.0.2-5.el6.1
Package scalapack-2.0.2-5.el6.1: * should fix your issue, * was pushed to the Fedora EPEL 6 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=epel-testing scalapack-2.0.2-5.el6.1' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-3534/scalapack-2.0.2-5.el6.1 then log in and leave karma (feedback).
*** Bug 1156344 has been marked as a duplicate of this bug. ***
Why is it necessary to use scalapack2 and change the library versions? I haven't had time to try yet, but I hope it will be possible to build compatibility packages (at least for openmpi, which we use) to keep binaries running through the mess of these incompatible MPI updates. Changing other ABIs will make that harder. Does v2 actually need the incompatible library version bump? I haven't had time to check as I'd intended for local packaging purposes, but the release notes suggest not, as expected.
Hmm, yeah I suppose the soname bump was unneeded. One problem with adding sonames downstream. I suppose it's possible that if we had kept the soname the same, it might have smoothed the transition for software that only linked to scalapack. But I suspect the most scalapack using software makes use of other mpi calls directly, and with mpi changes underneath I think it renders this point moot. And if the api didn't change, updating to 2.0.2 should not be an issue otherwise.
scalapack-2.0.2-5.el6.1 has been pushed to the Fedora EPEL 6 stable repository. If problems still persist, please make note of it in this bug report.