[Pkg-scicomp-devel] Bug#552429: [Pkg-openmpi-maintainers] Bug#552429: MPI: fix alternatives mess with runtime environment

[Lucas Nussbaum]

On 10/11/09 at 21:40 +0100, Manuel Prinz wrote:
> Hi Lucas!
> 
> Am Montag, den 26.10.2009, 09:04 +0100 schrieb Lucas Nussbaum:
> > Alternatives:
> > - for compilation environment:
> >   all implementations have a single "mpi" alternative. The master
> >   controls the link from /usr/include/mpi, and has all the compilers
> >   wrappers as slaves.
> >   => That's great, and there's nothing to do about it.
> 
> There are two issues I do have with that:
> 
> 1. Priorities:

I agree that OpenMPI and mpich2 should have the same priority. But this
can be fixed independently from the current alternatives problem.

> 2. libmpi.so (and others):
> 
> Some of the packages (MPICH2, Open MPI, LAM MPI) set libmpi.so via
> alternatives. This is very troublesome, as it is not ABI compatible
> between the implementations. I have not yet checked if packages are
> linked to libmpi.so directly, but if so, they will break as soon as the
> alternatives are switched. MPICH only manages the static libraries with
> alternatives which seems to be OK. (Though not really recommended,
> IMHO.) We should think about dropping this alternative or finding a
> solution. The compiler wrappers should be OK finding the libraries
> under /usr/lib/$pkg/. Alternatively, each package could provide a "lib
> $pkg.so" instead and drop libmpi.so from alternatives. One other option
> I can think of is to provide libmpi.so via mpi-defaults, so it can't be
> changed. All other mpi compilers should be able to work. (Have to test
> that.) Otherwise changing the compilation environment could crash
> applications since libmpi.so is moved to something they were not build
> against. Opinions?

How do reverse dependencies typically link against MPI implementations?

Dropping libmpi.so would break linking using -lmpi.

> > - for runtime environment:
> >   mpich2 and openmpi:
> >   two distinct mpirun and mpiexec alternatives (each master) to control
> >   those binaries
> >   mpich and lam-runtime:
> >   a single mpirun alternative that controls (as slaves) the other
> >   binaries (including mpiexec)
> > 
> > I think that it makes more sense to have mpirun and mpiexec be linked
> > together (the mpich/lam solution).
> 
> Dito. As far as Open MPI is concerned, mpirun and mpiexec are the same
> tool (opal_wrapper). I propose that every package should provide
> mpi{run,exec}.$pkg and manage it via the "mpirun" master alternative,
> including the man pages.

OK. That's really the first problem I'd like to solve, since it only
affects OpenMPI and MPICH2. The other problems can be addressed after
that.

Would it be enough to fix it in the postinst script, by removing the
previous alternatives and adding the new ones?

Actually, we could fix the priority at the same time. Setting the
priority for OpenMPI and MPICH2 to 40 would be OK.

Are you OK with all of this?
-- 
| Lucas Nussbaum
| lucas at lucas-nussbaum.net   http://www.lucas-nussbaum.net/ |
| jabber: lucas at nussbaum.fr             GPG: 1024D/023B3F4F |