Re: updating mpi-defaults (decommissioning lam)

[Manuel Prinz <manuel@debian.org>]

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.

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

Best regards,
Manuel