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

[Manuel Prinz]

Hi Thibaut,

thanks for clarifying! It seems to me that we share the same opinion in
(almost) all points but have a different view on the topic.

Am Donnerstag, den 25.03.2010, 16:57 +0100 schrieb Thibaut Paumard:
> 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).

Right, though my preferred solution would not use mpicc.default at all.
But this is not possible with touching some packages and needs thorough
testing. It's nothing to be done now. I plan to do this before the next
stable release after squeeze. Using update-alternatives is the wrong
approach. It would work if the implementations were ABI compatible. But
they aren't. (Hope the MPI 3 standard will fix this.)

> 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.

LAM is not a show-stopper here, since we're in the MPI transition to get
rid of it, or at least drop all dependencies on it.

> 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:

This is exactly what we're going for and what is started already (see
#573187). I thought you were aware of that.

>   1- raise the priority in OpenMPI

I just did that with the latest upload.

>   2- raise the priority of LAM OR make the transition to MPICH2.

As said above, the later one is already in progress. It just needs a
working upload of mpi-defaults and the preparation of some patches which
I currently work on.

> More profoundly, what I suggest here is to control which  
> implementation is default entirely from the mpi-defaults package.

Full ACK. But using update-alternatives is (generally speaking) the
wrong approach. But we have to live with it for now.

> Playing with the priorities of the various implementations is more  
> complex.

Agreed.

> 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.

Exactly. This is why we need a solution that does not rely on u-a at
all. This is possible and I could elaborate on that but as said, it will
take larger modifications. And it is not really relevant for this
transition, IMO.

So, given that the priority in Open MPI changed and we will transition,
do you think the patch is useful? I do not refrain from applying it to
mpi-default but my understanding is that we do not need to have it as of
now.

To be clear: I'm very much in favor of having a solution that works
correctly with whatever MPI implementation is chosen as the local
default. But u-a can not be used to realize that. Once the sysadmin set
the default manually, we have lost, no matter how high the priority of
the mpi-defaults alternative is.

Best regards,
Manuel