Your message dated Thu, 19 Nov 2009 16:19:05 -0600
with message-id <20091119221905.ga9...@xanadu.blop.info>
and subject line fixed in mpich2/1.2.1-1, openmpi/1.3.3-3
has caused the Debian Bug report #552429,
regarding MPI: fix alternatives mess with runtime environment
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
552429: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=552429
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
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
| lu...@lucas-nussbaum.net http://www.lucas-nussbaum.net/ |
| jabber: lu...@nussbaum.fr GPG: 1024D/023B3F4F |
--- End Message ---
--- Begin Message ---
Hi,
This is now fixed with my upload of mpich2/1.2.1-1, so I'm closing this
bug.
Thanks a lot for the healthy discussion in this bug.
--
| Lucas Nussbaum
| lu...@lucas-nussbaum.net http://www.lucas-nussbaum.net/ |
| jabber: lu...@nussbaum.fr GPG: 1024D/023B3F4F |
--- End Message ---
