Bug#575259: mpi-default-dev doesn't ensure that the right implementation is used

Manuel Prinz manuel at debian.org
Thu Mar 25 13:30:00 UTC 2010


> Le 24 mars 10 à 16:59, Lucas Nussbaum a écrit :
> > Actually, the information I was missing is that some packages depend  
> > on
> > mpi-default-dev. I thought that mpi-default-dev was only used as a
> > build-dependency. In that case, conflicting is indeed harmful, so the
> > only solution is the alternatives hack...

This is new to me as well. mpi-defaults-dev was supposed to be a build
dependency only. If packages depend on it, this is a bug.

Am Donnerstag, den 25.03.2010, 13:54 +0100 schrieb Thibaut Paumard:
> New patch implementing the mpicc.default alternative.

Thanks for the patch!

> I have only implemented .default links for the files which were  
> present in both openmpi and lam, so no mpif90.default.

This will be fixed with the next Open MPI upload, I will adjust your
patch respectively.

But there is still one thing I do not get: What problem is solved by
installing mpicc.default as alternative? If the sysadmin did change the
MPI implementation via update-alternatives, it will stay that way. It
has no benefit over simply providing mpicc.default as symlink to the
implementation prefered on the arch, not handled via alternatives. If
the sysadmin did not change it, increasing the priority of the openmpi
alternative will save the same purpose. So updating the priority and
just providing symlinks should be enough, AIUI. But please correct me if
I'm wrong. I did not test this, yet.

The thing we need to rely on is that the alternative is not changed. I
mentioned quite a while back (in a different discussion) that I consider
the alternatives system wrong for the case of MPI and that pretty much
shows here. Nevertheless, it is the (best?) solution we have at the
moment and we simply have to make the assumption that noone fiddles with
the alternatives systems on the buildds. I guess that is quite safe to
assume. I do not care that much for the developers' systems right now,
but only for the transition; a more developer-friendly solution has to
be (and will) be found after the release.

Thanks to both of you for your efforts! It's very much appreciated!

Best regards,
Manuel






More information about the debian-science-maintainers mailing list