Le 25 mars 10 à 14:30, Manuel Prinz a écrit :

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.


Installing mpicc.default as an alternative is to make sure the default implementation has a high priority. It is to fix the problem at hand for the packages which already exist, since new packages should call mpicc.default directly (IMHO).

Currently, LAM is the default on some architectures and has a lower priority than MPICH2. OpenMPI is the default on the other arches, and MPICH2 still wins.

The solution I propose fixes the problem with a single upload, no transition needed. To really fix the problem without installing .default as an alternative, you need at least two uploads:

 1- raise the priority in OpenMPI
 2- raise the priority of LAM OR make the transition to MPICH2.

More profoundly, what I suggest here is to control which implementation is default entirely from the mpi-defaults package. Playing with the priorities of the various implementations is more complex. Also, as Lucas mentioned, what happens if you decide that MPICH2 has to be the default on a given arch where OpenMPI also exists because the former is more stable on that particular arch? If you rely on the relative priorities of the two packages, you have to install the alternatives with a different priority depending on the architecture... Becomes really nasty.

Best regards, Thibaut.




--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Reply via email to