Bug#552429: MPI: fix alternatives mess with runtime environment

[Lucas Nussbaum]

Source: openmpi,mpich2,lam,mpich
Severity: serious

Hi,

The different MPI implementations currently handle alternatives
differently, resulting in a lot of nasty bugs when two implementations
are installed together, like that:
> update-alternatives: error: alternative mpiexec can't be slave of
> mpirun: it is a master alternative.
> dpkg: error processing lam-runtime (--configure):
>  subprocess installed post-installation script returned error exit
>  status 2
>  Setting up lam4-dev (7.1.2-1.5) ...
>  update-alternatives: using /usr/include/lam to provide /usr/include/mpi
>  (mpi) in auto mode.
>  Errors were encountered while processing:
>   lam-runtime
>   E: Sub-process /usr/bin/dpkg returned an error code (1)

We need to decide on the same set of alternatives, and implement it in
all the MPI packages. Here is the current status:

Packages:
implementation | pkg with mpicc  | pkg with mpirun
--------------------------------------------------
lam-mpi        | lam4-dev        | lam-runtime
mpich          | libmpich1.0-dev | mpich-bin
openmpi        | libopenmpi-dev  | openmpi-bin
mpich2         | libmpich2-dev   | mpich2

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

Any ideas?
-- 
| Lucas Nussbaum
| lucas at lucas-nussbaum.net   http://www.lucas-nussbaum.net/ |
| jabber: lucas at nussbaum.fr             GPG: 1024D/023B3F4F |