Le mardi 04 mars 2014 à 14:48 +0100, Julien Cristau a écrit : > On Mon, Mar 3, 2014 at 18:24:06 +0100, Sébastien Villemot wrote: > > > Please schedule a binNMU for scalapack on s390x. > > > > The shared library of scalapack/s390x currently has unsatisfied shared library > > dependencies: > > > > (sid_s390x-dchroot)sebastien@zelenka:~$ ldd /usr/lib/libscalapack-mpich2.so > > [...] > > libblacsCinit-mpich2.so.1 => not found > > libblacs-mpich2.so.1 => not found > > > > (sid_s390x-dchroot)sebastien@zelenka:~$ ls /usr/lib/libblacs*.so.1 > > /usr/lib/libblacsCinit-mpich.so.1 /usr/lib/libblacsF77init-mpich.so.1 /usr/lib/libblacs-mpich.so.1 > > > > > > This state of affairs is due to the mpich2->mpich transition, which made > > blacs-mpi change the name of its shared libraries (due to the way this package > > handles the openmpi vs mpich archs). > > > > Also note that this scalapack issue is causing petsc to FTBFS on s390x, and is > > therefore blocking the ongoing superlu transition (but don't give back petsc, > > it will need new a sourceful upload to get fixed). > > > > nmu scalapack_1.8.0-9 . s390x . -m "rebuild against a blacs-mpi built against MPICH 3" > > > If that means a mere rebuild changes scalapack's SONAME, then very much > NAK. SONAME changes should always go with a binary package name change. There seem to be several package (at least blacs-mpi and scalapack, possibly others) who construct the SONAME at build time using the name of the default MPI implementation. This effectively implies a SONAME change when the name of a given implementation changes (as in the current case); it also means a SONAME change when the default implementation changes on a given arch. So if I understand your point correctly, one option would be to name the package libscalapack-openmpi1 on openmpi archs, and libscalapack-mpich1 on mpich archs (same for blacs-mpi). But I guess this would mean that changes of default MPI implementation on a given arch would require sourceful uploads of packages following this scheme, not just binNMUs. Another solution would be to remove the name of the MPI implementation from the SONAME. But maybe that would have the consequence of silently breaking packages when a given arch changes of default MPI implementation. I don't know what's the right fix. Someone has to fix this whole MPI mess, but I'm personally not very motivated. -- .''`. Sébastien Villemot : :' : Debian Developer `. `' http://www.dynare.org/sebastien `- GPG Key: 4096R/381A7594
Attachment:
signature.asc
Description: This is a digitally signed message part