Bug#552429: MPI: fix alternatives mess with runtime environment
On 18/11/09 at 16:01 +0100, Manuel Prinz wrote: Am Mittwoch, den 18.11.2009, 07:35 -0600 schrieb Lucas Nussbaum: Yeah, but the unconditional --removal-all looks a bit scary :-) I know. There was discussion about that on the dpkg mailing list, IIRC. Other packages had similar problems. The recommended solution was to remove all and let u-a recreate the entries in postinst. My memory may be bad here, though. Anyway, you're fix is a lot nicer. ;) Do you want me to upload an NMU ? I have time this week. If you'd like to, feel free to do an 0-day NMU. If Sylvestre doesn't have any objections, of course. It would be cool if you could mail the debdiff, so that I can include it in our repository. TIA! Hi, I just uploaded openmpi 1.3.3-3.1 with my fixes. Attached is the debdiff. -- | Lucas Nussbaum | lu...@lucas-nussbaum.net http://www.lucas-nussbaum.net/ | | jabber: lu...@nussbaum.fr GPG: 1024D/023B3F4F | reverted: --- openmpi-1.3.3/debian/openmpi-bin.preinst +++ openmpi-1.3.3.orig/debian/openmpi-bin.preinst @@ -1,15 +0,0 @@ -#!/bin/sh - -set -e - -# mpirun and mpiexec seemed to be used as a master alternative by some MPI -# package. But currently, all MPI packages have the mpicc alternative installed -# as a slave link. We remove the link here in order to resolve bug #532008, -# #534740, and #544372. - -update-alternatives --quiet --remove-all mpirun /dev/null 21 || true -update-alternatives --quiet --remove-all mpiexec /dev/null 21 || true - -#DEBHELPER# - -exit 0 diff -u openmpi-1.3.3/debian/openmpi-bin.prerm openmpi-1.3.3/debian/openmpi-bin.prerm --- openmpi-1.3.3/debian/openmpi-bin.prerm +++ openmpi-1.3.3/debian/openmpi-bin.prerm @@ -4,7 +4,6 @@ if [ $1 != upgrade ]; then update-alternatives --remove mpirun /usr/bin/mpirun.openmpi - update-alternatives --remove mpiexec /usr/bin/mpiexec.openmpi fi #DEBHELPER# diff -u openmpi-1.3.3/debian/changelog openmpi-1.3.3/debian/changelog --- openmpi-1.3.3/debian/changelog +++ openmpi-1.3.3/debian/changelog @@ -1,3 +1,10 @@ +openmpi (1.3.3-3.1) unstable; urgency=low + + * Non-maintainer upload with the maintainer's permission. + * Improve alternatives upgrade. + + -- Lucas Nussbaum lu...@lucas-nussbaum.net Thu, 19 Nov 2009 16:44:20 -0600 + openmpi (1.3.3-3) unstable; urgency=low * Removed mpiexec alternative, as discussed in #552429. It is now a slave diff -u openmpi-1.3.3/debian/openmpi-bin.postinst openmpi-1.3.3/debian/openmpi-bin.postinst --- openmpi-1.3.3/debian/openmpi-bin.postinst +++ openmpi-1.3.3/debian/openmpi-bin.postinst @@ -2,7 +2,26 @@ set -e -update-alternatives --quiet --remove-all mpiexec /dev/null 21 || true +case $1 in + configure) + # Continue below + ;; + abort-upgrade|abort-remove|abort-deconfigure) + exit 0; + ;; + *) + echo postinst called with unknown argument \`$1' 2 + exit 0; + ;; +esac + +# so, we are running with $1 = configure +# openmpi versions before 1.3.3-2 were using two alternatives where other +# MPI implementations were using only one, which breaks. Clean up +# our mess. +if [ $2 != ] dpkg --compare-versions $2 le 1.3.3-2; then +update-alternatives --remove mpiexec /usr/bin/mpiexec.openmpi +fi update-alternatives \ --install /usr/bin/mpirun mpirun /usr/bin/mpirun.openmpi 40 \
Bug#552429: MPI: fix alternatives mess with runtime environment
Hi Lucas! Am Dienstag, den 17.11.2009, 23:38 -0600 schrieb Lucas Nussbaum: I'm still not convinced. For example, in preinst, you probably shouldn't --remove-all mpirun. Attached is a patch that works (apparently). I plan to do something very similar in mpich2. Can you review/comment? Thanks for the patch. It indeed looks cleaner than my changes but I tested them with several MPI implementations installed and it always gave proper results. I'll test and apply your patch nevertheless, as it should not have side effects. Thanks for working on that! I'm drowning in work at the moment, so I will not be able to upload a fixed version before Friday or Saturday. Best regards Manuel -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#552429: MPI: fix alternatives mess with runtime environment
On 18/11/09 at 13:29 +0100, Manuel Prinz wrote: Hi Lucas! Am Dienstag, den 17.11.2009, 23:38 -0600 schrieb Lucas Nussbaum: I'm still not convinced. For example, in preinst, you probably shouldn't --remove-all mpirun. Attached is a patch that works (apparently). I plan to do something very similar in mpich2. Can you review/comment? Thanks for the patch. It indeed looks cleaner than my changes but I tested them with several MPI implementations installed and it always gave proper results. I'll test and apply your patch nevertheless, as it should not have side effects. Thanks for working on that! Yeah, but the unconditional --removal-all looks a bit scary :-) I'm drowning in work at the moment, so I will not be able to upload a fixed version before Friday or Saturday. Do you want me to upload an NMU ? I have time this week. I'll also use the same code in mpich2, and test them together. -- | 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
Bug#552429: MPI: fix alternatives mess with runtime environment
Am Mittwoch, den 18.11.2009, 07:35 -0600 schrieb Lucas Nussbaum: Yeah, but the unconditional --removal-all looks a bit scary :-) I know. There was discussion about that on the dpkg mailing list, IIRC. Other packages had similar problems. The recommended solution was to remove all and let u-a recreate the entries in postinst. My memory may be bad here, though. Anyway, you're fix is a lot nicer. ;) Do you want me to upload an NMU ? I have time this week. If you'd like to, feel free to do an 0-day NMU. If Sylvestre doesn't have any objections, of course. It would be cool if you could mail the debdiff, so that I can include it in our repository. TIA! Best regards Manuel -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#552429: [Pkg-openmpi-maintainers] Bug#552429: Bug#552429: MPI: fix alternatives mess with runtime environment
On 11/11/09 at 22:34 +0100, Manuel Prinz wrote: Am Mittwoch, den 11.11.2009, 14:13 +0100 schrieb Lucas Nussbaum: Let's fix the only really broken thing: the mpiexec/mpirun problem in openmpi and mpich2. After that, we can downgrade this bug and discuss the rest of it. I uploaded a fixed package a few minutes ago that uses mpirun as master alternative and raised the priority to 40 for alternatives mpirun (openmpi-bin) and mpi (libopenmpi-dev). Hi Manuel, I'm still not convinced. For example, in preinst, you probably shouldn't --remove-all mpirun. Attached is a patch that works (apparently). I plan to do something very similar in mpich2. Can you review/comment? -- | Lucas Nussbaum | lu...@lucas-nussbaum.net http://www.lucas-nussbaum.net/ | | jabber: lu...@nussbaum.fr GPG: 1024D/023B3F4F | diff -u openmpi-1.3.3/debian/openmpi-bin.preinst openmpi-1.3.3/debian/openmpi-bin.preinst --- openmpi-1.3.3/debian/openmpi-bin.preinst +++ openmpi-1.3.3/debian/openmpi-bin.preinst @@ -2,14 +2,6 @@ set -e -# mpirun and mpiexec seemed to be used as a master alternative by some MPI -# package. But currently, all MPI packages have the mpicc alternative installed -# as a slave link. We remove the link here in order to resolve bug #532008, -# #534740, and #544372. - -update-alternatives --quiet --remove-all mpirun /dev/null 21 || true -update-alternatives --quiet --remove-all mpiexec /dev/null 21 || true - #DEBHELPER# exit 0 diff -u openmpi-1.3.3/debian/openmpi-bin.prerm openmpi-1.3.3/debian/openmpi-bin.prerm --- openmpi-1.3.3/debian/openmpi-bin.prerm +++ openmpi-1.3.3/debian/openmpi-bin.prerm @@ -4,7 +4,6 @@ if [ $1 != upgrade ]; then update-alternatives --remove mpirun /usr/bin/mpirun.openmpi - update-alternatives --remove mpiexec /usr/bin/mpiexec.openmpi fi #DEBHELPER# diff -u openmpi-1.3.3/debian/changelog openmpi-1.3.3/debian/changelog --- openmpi-1.3.3/debian/changelog +++ openmpi-1.3.3/debian/changelog @@ -1,3 +1,9 @@ +openmpi (1.3.3-4) unstable; urgency=low + + * Fix alternatives upgrade. + + -- Lucas Nussbaum lu...@lucas-nussbaum.net Tue, 17 Nov 2009 16:36:55 -0600 + openmpi (1.3.3-3) unstable; urgency=low * Removed mpiexec alternative, as discussed in #552429. It is now a slave diff -u openmpi-1.3.3/debian/openmpi-bin.postinst openmpi-1.3.3/debian/openmpi-bin.postinst --- openmpi-1.3.3/debian/openmpi-bin.postinst +++ openmpi-1.3.3/debian/openmpi-bin.postinst @@ -2,7 +2,26 @@ set -e -update-alternatives --quiet --remove-all mpiexec /dev/null 21 || true +case $1 in + configure) + # Continue below + ;; + abort-upgrade|abort-remove|abort-deconfigure) + exit 0; + ;; + *) + echo postinst called with unknown argument \`$1' 2 + exit 0; + ;; +esac + +# so, we are running with $1 = configure +# openmpi versions before 1.3.3-2 were using two alternatives where other +# MPI implementations were using only one, which breaks. Clean up +# our mess. +if [ $2 != ] dpkg --compare-versions $2 le 1.3.3-2; then +update-alternatives --remove mpiexec /usr/bin/mpiexec.openmpi +fi update-alternatives \ --install /usr/bin/mpirun mpirun /usr/bin/mpirun.openmpi 40 \
Bug#552429: [bal...@mcs.anl.gov: Re: Bug#552429: [Pkg-openmpi-maintainers] Bug#552429: MPI: fix alternatives mess with runtime environment]
- Forwarded message from Pavan Balaji bal...@mcs.anl.gov -
On 11/10/2009 02:40 PM, Manuel Prinz wrote:
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
MPICH2 and Open MPI should have the same priority, isn't it? They are
just alternative implementations of MPI.
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?
MPICH2 creates libmpich.so, not libmpi.so
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.
mpiexec and mpirun are the same even in MPICH2. mpiexec is required by
the MPI standard, so all implementations provide it. mpirun is just kept
around for backward compatibility since the MPI-1 days.
I think there's a lot of confusion about MPICH2 on this email thread.
I'll be happy to clarify any questions.
Thanks,
-- Pavan
--
Pavan Balaji
http://www.mcs.anl.gov/~balaji
- End forwarded message -
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#552429: [Pkg-openmpi-maintainers] Bug#552429: MPI: fix alternatives mess with runtime environment
On Tue, 2009-11-10 at 15:29 -0600, Pavan Balaji wrote: MPICH2 and Open MPI should have the same priority, isn't it? They are just alternative implementations of MPI. Thought about that too but I am unsure how update-alternatives handles that case. The man page talks about only taking action if a priority is higher than the other. It does not mention the special case where they are equal. I did not want to lower MPICH2's importance or something like that; just to have distinct values so I can avoid the need to fix update-alternatives related bugs (again). ;) mpiexec and mpirun are the same even in MPICH2. mpiexec is required by the MPI standard, so all implementations provide it. mpirun is just kept around for backward compatibility since the MPI-1 days. I was not aware of that. So maybe using mpiexec as the master alternative might be better/more intuitive? I think there's a lot of confusion about MPICH2 on this email thread. I'll be happy to clarify any questions. Not sure if it's specifically about MPICH2. My feeling is that it's more of the general character of dealing with multiple MPI implementations inside the distribution. Best regards Manuel -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#552429: [Pkg-openmpi-maintainers] Bug#552429: MPI: fix alternatives mess with runtime environment
On 11/11/09 at 11:23 +0100, Manuel Prinz wrote: mpiexec and mpirun are the same even in MPICH2. mpiexec is required by the MPI standard, so all implementations provide it. mpirun is just kept around for backward compatibility since the MPI-1 days. I was not aware of that. So maybe using mpiexec as the master alternative might be better/more intuitive? I would vote for keeping it as is, so we don't need to change LAM and mpich. It's not really exposed to users anyway. -- | 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
Bug#552429: [Pkg-openmpi-maintainers] Bug#552429: MPI: fix alternatives mess with runtime environment
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
| 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
Bug#552429: [Pkg-openmpi-maintainers] Bug#552429: MPI: fix alternatives mess with runtime environment
On Wed, 2009-11-11 at 13:43 +0100, Lucas Nussbaum wrote: I would vote for keeping it as is, so we don't need to change LAM and mpich. It's not really exposed to users anyway. I'm fine with that. Best regards Manuel -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#552429: [Pkg-openmpi-maintainers] Bug#552429: MPI: fix alternatives mess with runtime environment
As for the mpi.so thing: Forget about it, confusion on my part. Not a problem at all. On Wed, 2009-11-11 at 13:54 +0100, Lucas Nussbaum wrote: 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? That should be sufficient, yes. 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? Yes. I'll patch Open MPI tonight. But how about Adam's concerns? I think it is reasonable to add the Fortran libs to the alternative while we're at it. Best regards Manuel -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#552429: [Pkg-openmpi-maintainers] Bug#552429: MPI: fix alternatives mess with runtime environment
On 11/11/09 at 14:07 +0100, Manuel Prinz wrote: As for the mpi.so thing: Forget about it, confusion on my part. Not a problem at all. On Wed, 2009-11-11 at 13:54 +0100, Lucas Nussbaum wrote: 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? That should be sufficient, yes. 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? Yes. I'll patch Open MPI tonight. But how about Adam's concerns? I think it is reasonable to add the Fortran libs to the alternative while we're at it. This needs to be coordinated between all the MPI implementations, because you wouldn't be able to have LAM without the fortran lib alternative installed together with openmpi with the fortran lib alternative. So I'm not sure that we want to switch to that *now*. Let's fix the only really broken thing: the mpiexec/mpirun problem in openmpi and mpich2. After that, we can downgrade this bug and discuss the rest of it. -- | 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
Bug#552429: [Pkg-openmpi-maintainers] Bug#552429: MPI: fix alternatives mess with runtime environment
On 11/11/2009 06:54 AM, Lucas Nussbaum wrote: Dropping libmpi.so would break linking using -lmpi. Applications should never just link directly against either libmpi.so or libmpich.so or anything else. They should always use mpicc and friends. Linking directly to a library without using mpicc and friends will break when MPICH2's I/O library enables support for some third-party libraries such as PVFS, for example. It'll automatically add more library flags to mpicc and friends, but the symbols are not added into libmpich.so Note that this is not the case for MPICH2 alone, but for any MPI implementation. For example, Open MPI uses our MPI I/O library, so they have the same problem too. -- Pavan -- Pavan Balaji http://www.mcs.anl.gov/~balaji -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#552429: [Pkg-openmpi-maintainers] Bug#552429: Bug#552429: MPI: fix alternatives mess with runtime environment
Am Mittwoch, den 11.11.2009, 14:13 +0100 schrieb Lucas Nussbaum: Let's fix the only really broken thing: the mpiexec/mpirun problem in openmpi and mpich2. After that, we can downgrade this bug and discuss the rest of it. I uploaded a fixed package a few minutes ago that uses mpirun as master alternative and raised the priority to 40 for alternatives mpirun (openmpi-bin) and mpi (libopenmpi-dev). Best regards Manuel -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#552429: MPI: fix alternatives mess with runtime environment
While we're at it, can we add a slave to mpi which links to the fortran MPI library? There are a bunch of packages which could use this, they currently have to figure out which MPI is installed in order to build, which shouldn't be necessary. -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Bug#552429: [Pkg-openmpi-maintainers] Bug#552429: MPI: fix alternatives mess with runtime environment
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
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
Bug#552429: MPI: fix alternatives mess with runtime environment
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
