Re: updating mpi-defaults (decommissioning lam)
On Sat, 2011-04-09 at 14:12 +0200, Manuel Prinz wrote:
Sorry for jumping in late, I'm recovering from a servere cold at the moment.
> I'll probably have some delay in responding in the next days, as I'm not fully
> recovered.
>
Thanks for replying with the update. No big rush on it, I'm away myself
on holidays next week.
> On Fri, Apr 08, 2011 at 10:54:47AM +1000, Drew Parsons wrote:
> > I'm happy to leave bug #575259 untouched if you suspect the patch might
> > be unreliable. I just want lam gone so packages can autobuild. I have
> > no substantial preference between openmpi and mpich2, unless mpich2
> > should give the same build problems that lam did.
>
> I do not think it is reliable and needs further testing. I'll give a short
> summary of what is going on in this direction and we should discuss how to
> proceed:
>
> - I'm currently packaging Open MPI 1.5 and am working with upstream to
> add support for currently unsupported architectures. It's looking quite
> good so openmpi will build on at least armel and mips(el), maybe others
> or even all architectures.
> - I'd prefer to fix mpi-defautls once we have both openmpi and mpich2 build
> on all architectures, so that we can go for one. (I'm not really in favor
> for one or the other.)
>
Judging by the build logs at
https://buildd.debian.org/pkg.cgi?pkg=mpich2, mpich2 is already building
on all architectures. Will be nice to have openmpi available everywhere
too though (not that people will be setting up mpi jobs across their
armel smartphones, but it's the principle of the matter... :) ).
- Using update-alternatives in the MPI packages to replace a library did
> always bother me and I think this is broken. We should consider modifying
> the packages in a way so that mpi-defaults would provide libmpi.so. I did
> not check how a migration path would look like, though.
>
> My preferred way of action would be to update openmpi (ABI change, needs
> transition anyway), modify mpi-defaults to drop LAM and get rid of LAM and
> MPICH archive-wide, as proposed for the last release. This is not the fastest
> solution, but IMHO the most reasonable. I'm open for other suggestions, of
> course.
>
This sounds reasonable to me. My only question is, what timeframe could
we expect the openmpi updates (armel, mips[el] [s390?]) to take? Should
we set some deadline at which point we say we can't wait any longer, and
then push a mixed mpi-defaults with mpich2 on armel/mips (or promote
mpich2 on all archs) ?
A related side question: what are the current pros/cons of openmpi vs
mpich2, aside from architecture support?
If I understood correctly, it will fit your action plan better if I hold
off uploading a new mpi-defaults for now. I'm happy to wait a little
longer :)
Drew
Reply to: