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 | -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
