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 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/1302419585.4651.20.camel@pug
