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

[Manuel Prinz]

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:

The priorities currently used by the alternatives are the following:

LAM MPI: 30
MPICH:   10
Open MPI: 5
MPICH2:   5

This does not reflect the fact that LAM and MPICH should go in the long
run. I propose to change the priorities to:

Open MPI: 20
MPICH2:   15
MPICH:     5
LAM MPI:   5

Maybe Open MPI and MPICH2 should have the same value but I do not know
if update-alternatives handles that reasonably. The numbers have no
special meaning, I just set them so the ordering is OK.

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?

> - 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.

Best regards
Manuel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
URL: <http://lists.alioth.debian.org/pipermail/pkg-scicomp-devel/attachments/20091110/d636ba1c/attachment.pgp>