Hi, Le 23 mars 10 à 19:01, Manuel Prinz a écrit :
To comment on the discussions you had: The problem Thibaut mentions onlyexists on the platforms where both implementations exist and mpich2 is installed later into a buildd chroot.
Actually, I was wrong about that: from toying around with the two packages, it seems update-alternatives falls back to lexicological order when the priorities are the same, so mpich2 always has precedence over openmpi.
Mpich2 also has a priority higher than LAM, which is buggy as long as the default is LAM when OpenMPI is not available, but the plan is to make MPICH2 the default in that case anyway.
The easiest (and cleanest) solution seems to be to add mpicc.default and friends (or whatever we call it) to mpi-defaults-dev, being symlinks tothe default mpicc on that platform. Those can be used by the packages using only mpi-defaults-dev. The only downside I see right now it the fact that we should fix all packages not using it also which has a negative effect on the whole transition. On the other hand, we do notneed to; it won't break anything if the assumptions made are valid. (Butas said, we can't really rely to it.)
And as I stated earlier, you can install mpicc.default as an alternative for mpicc with a high priority. So mpicc wil really point to the right implementation unless the admin has chosen otherwise, which buildd admins should not do.
I could also increase the update-alternatives priority of Open MPI tosomething higher than MPICH2. This should have no negative side effects but does of course not fix the current problem. What do you think aboutthat? (Planning to upload some minor fixes to Open MPI anyway.)
I think it is an easy solution that indeed mostly solves the problem for the time being, with no foreseeable nasty side effects.
Regards, Thibaut.