[Pkg-openmpi-maintainers] Bug#452047: libopenmpi-dev: /usr/lib/libmpi.so conflicts with other packages' alternatives

[Nicholas Breen]

Forwarding a gromacs-openmpi bug that I cloned to libopenmpi-dev to the
list as a whole:

------------------------------------

On Mon, Nov 19, 2007 at 06:36:35PM +0100, Manuel Prinz wrote:
> gromacs-openmpi depends on lam4c2 which seems to be wrong. I think it's
> related to #451991 but I'm not sure, so I file it as a seperate bug. (I'm
> not sure about the severity either.)

As best I can tell, the problem here is that libopenmpi-dev ships
/usr/lib/libmpi.so as a file (symlink) in the package itself, while both
LAM (lam4c2, lam4-dev) and MPICH (libmpich1.0ldbl, libmpich1.0-dev) do
not have it in the file list, but *do* reference it as part of their
update-alternatives(1) configuration.  As a result, depending on what
order the packages are installed in, you can end up with a symlink
pointing to a LAM or MPICH library, while dpkg still registers the
filename as belonging to OpenMPI.  This in turn causes link errors
during compilation and improper dependencies from dpkg-shlibdeps.

As a demonstration, starting from a clean slate:
# aptitude purge libmpich1.0ldbl libmpich1.0-dev lam4c2 lam4-dev libopenmpi1 libopenmpi-dev
# aptitude install libopenmpi1 libopenmpi-dev 
# aptitude install lam4c2 lam4-dev libmpich1.0ldbl libmpich1.0-dev

# ls -l /usr/lib/libmpi.so*
lrwxrwxrwx 1 root root     27 2007-11-19 18:54 /usr/lib/libmpi.so -> /etc/alternatives/libmpi.so
lrwxrwxrwx 1 root root     15 2007-11-19 18:54 /usr/lib/libmpi.so.0 -> libmpi.so.0.0.0
-rw-r--r-- 1 root root 513660 2007-10-06 06:06 /usr/lib/libmpi.so.0.0.0

Here, libmpi.so.0.0.0 is from libopenmpi1.  The libmpi.so link is where
the problem arises:

# readlink -f /usr/lib/libmpi.so 
/usr/lib/liblam.so.4.0

# dpkg -S /usr/lib/libmpi.so /usr/lib/liblam.so.4.0
libopenmpi-dev: /usr/lib/libmpi.so
lam4c2: /usr/lib/liblam.so.4.0

I've set the bug severity at serious because this is a filename overlap
between packages (Policy 10.1), which dpkg does not catch because
LAM/MPICH create the conflicting filename in their postinst scripts.  If
OpenMPI is installed *after* the other two, builds work as expected, but
this can't be enforced on the buildds.

Both lam4-dev and libopenmpi-dev ship their equivalents to libmpi.so
under different original filenames and directories (/usr/lib/liblam.so
and /usr/lib/mpich/lib/shared/libmpich.so, respectively), underneath an
update-alternatives group using /usr/include/mpi as the master node.  In
turn, binaries generally link against the original library path/filename
instead of /usr/lib/libmpi.so.  OpenMPI does not do so - its
dependencies link against /usr/lib/libmpi.so directly, and it doesn't
share the same update-alternatives master node.

% mpicc.lam -showme
gcc -I/usr/lib/lam/include -pthread -L/usr/lib/lam/lib -llammpio -llamf77mpi -lmpi -llam -lutil -ldl
                                    ^^^^^^^^^^^^^^^^^^ no equivalent with mpicc.openmpi -showme

I think the solution is relocating OpenMPI's libmpi.so in a similar
manner to the other MPI packages, joining the same update-alternatives
scheme, and then recompiling its reverse dependencies.  Does that sound
correct, or even reasonably possible?


-- 
Nicholas Breen
nbreen at ofb.net



----- End forwarded message -----