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 -- To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110409121240.GA6273@woodstock