Hi,
Le 23 mars 10 à 19:01, Manuel Prinz a écrit :
To comment on the discussions you had: The problem Thibaut mentions
only
exists 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
to
the 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 not
need to; it won't break anything if the assumptions made are valid.
(But
as 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 to
something higher than MPICH2. This should have no negative side
effects
but does of course not fix the current problem. What do you think
about
that? (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.
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
Archive: http://lists.debian.org/[email protected]
