On Mon, 2007-12-17 at 14:47 -0600, Dirk Eddelbuettel wrote: > On 17 December 2007 at 21:13, Manuel Prinz wrote: > | Am Montag, den 17.12.2007, 13:36 -0600 schrieb Dirk Eddelbuettel: > | > Indeed, what were we thinking here Manuel? [...] In light of this, can > | > you remind me why you put the libs into /usr/lib/openmpi ? I > | > understand why we put the _internal_ library files like [files > | > snipped] there, but for the visible libraries were are introducing > | > breakage by hiding them. I am leaning towards pulling them back. Am > | > I overlooking something? > | > | The reasoning behind that was to fix the breaking of other MPI > | implementations by moving stuff to /usr/lib/openmpi/* and using > > But that was just libmpi.so(.so)*, wasn't it? > > | alternatives. At a first glance it seems like I messed something up with > | alternatives, not creating the links in the right place or something > | like that. So I fu**ed that up. I'm sorry! > > I'm at work too so I didn't have time to check yet. Recall that the final > links are actually created by the debhelper tools in conjunction with ldd, ie > what 'dpkg -c' typically shows at the end > > lrwxrwxrwx root/root 0 2007-12-12 13:13 > ./usr/lib/openmpi/lib/libopen-pal.so.0 -> libopen-pal.so.0.0.0 > lrwxrwxrwx root/root 0 2007-12-12 13:13 > ./usr/lib/openmpi/lib/libmpi.so.0 -> libmpi.so.0.0.0 > lrwxrwxrwx root/root 0 2007-12-12 13:13 > ./usr/lib/openmpi/lib/libmpi_f77.so.0 -> libmpi_f77.so.0.0.0 > lrwxrwxrwx root/root 0 2007-12-12 13:13 > ./usr/lib/openmpi/lib/libmpi_cxx.so.0 -> libmpi_cxx.so.0.0.0 > lrwxrwxrwx root/root 0 2007-12-12 13:13 > ./usr/lib/openmpi/lib/libmpi_f90.so.0 -> libmpi_f90.so.0.0.0 > lrwxrwxrwx root/root 0 2007-12-12 13:13 > ./usr/lib/openmpi/lib/libopen-rte.so.0 -> libopen-rte.so.0.0.0 > lrwxrwxrwx root/root 0 2007-12-12 13:13 > ./usr/lib/openmpi/lib/libmca_common_sm.so.0 -> libmca_common_sm.so.0.0.0 > > are already symlinks. I am thoroughly confused now as to what we should do > in terms a superior technical solution. And quite frankly, I *personally* > don't care if we can co-exists with LAM and MPICH as I don't use those. > That said, this somewhat radical view is not the one I recommend as package > co-maintainer. We should play nice with the other _if possible_ without > hideous hacks. > > Adam, any hints other 'whatever, just make it work? ' ? ;-)
As the maintainer of mpich, I do not see any conflicts here. libmpich1.0ldbl has: libmpich.so.1.0, libfmpich.so.1.0, libpmpich.so.1.0, libpmpich++.so.1.0, libtvmpich.so.1.0, and libmpe.so.1.0 . There's no ABI compatibility between any of the MPI implementations, so the sonames should be different, and then there will be no conflict in /usr/lib right? If we want to take advantage of API compatibility, then the -dev package .so files should be alternatives symlinks, which they are. But not the soname-named symlinks. These should only overlap if there is ABI compatibility, as with the various BLAS and LAPACK implementations. If LAM and OpenMPI conflict, then IMO LAM should defer to OpenMPI for the reasons found in http://www.open-mpi.org/faq/?category=general#why : the LAM project has merged with OpenMPI and its maintainers have joined the OpenMPI team! -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
