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

Thibaut Paumard paumard at users.sourceforge.net
Thu Mar 25 15:57:44 UTC 2010


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.






More information about the debian-science-maintainers mailing list