[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

MPI in Debian (Was: Re: building package with different libs)



> On Thu, 2008-10-30 at 15:21 +0100, Manuel Prinz wrote:
> > ACK to that. The problem will probably not go away anytime soon. A new
> > standard seems to be on the way, and I really hope things improve with
> > it.

Am Donnerstag, den 30.10.2008, 19:48 -0400 schrieb Adam C Powell IV:
> Wow, that would be great!  Do you have a link where I can learn more?

Unfortunately, no. I remember having heared Jeff Squyres talking about
that in the introduction screencast to OpenMPI [0] but I might be wrong
here. The MPI Forum released version 2.1 in September [1] but I'm not
too sure if that what Jeff was talking about. I have not had a look into
the documents yet.

> > As one of the OpenMPI maintainers, I can just agree to that. Though the
> > situation might seem bad, efforts are made with upstream to support the
> > yet unsupported platforms. I hope we can fix that for Squeeze and am
> > quite confident that this is possible. We're on it, but it will take
> > some time.
> 
> Indeed.  I'm afraid I dropped the ball on bugs 471886 (extend
> libatomic-ops-dev) and 376833 (make OpenMPI work everywhere).  I'll see
> if I can get some time for that, though 494046 (OpenMPI doesn't work in
> chroot) is my own higher priority at this point.
> 
> Do you know of other ways people are working on this?

No. I hope to get around on working on some of those during the weekend.
We have a patch that might add atomic ops on MIPS but is not yet tested.
If this works well, I will spent some time on your libatomic-ops-dev
patch. Getting MPI to work on all arches is my highest priority at the
moment. But that is probably nothing that can be sorted out in a day or
two, so don't expect it to work next Monday! ;)

> This is an interesting proposal.

And an official one. (Well, too late for that now, I guess.) Of course
we have to get in touch with everyone involved before starting to go
down that road. But if there are no objections, it's a "personal release
goal for Squeeze", if you like.

> If LAM upstream is dead, I too would
> support removing its dependencies -- but leaving LAM itself for users,
> as you suggest.  The list of packages which currently build -lam
> versions everywhere is: hdf5, scalapack, gromacs, netpipe, pgapack,
> blacs-mpi.  I've submitted patches to add -openmpi versions to scalapack
> and blacs-mpi, which have gone ignored (my hdf5 patch was accepted).
> 
> As for -lam where there's no openmpi, I only know of petsc and babel.

Thanks for the list!

> Then again, MPICH1 is also dead upstream, and MPICH2 is not in Debian.
> Should we remove all of those dependencies as well?

I have no idea how many people actually still use MPICH and I think it
has the second largest user base but I have no numbers to back up that
claim. I do not mind supporting MPICH and OpenMPI in Debian but we
surely should not support every implementation out there, simply because
they exist.

Is there any reason why MPICH2 is not in Debian?

Best regards
Manuel

[0] http://www.open-mpi.org/video/?category=general
[1] http://www.mpi-forum.org/docs/docs.html

Attachment: signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil


Reply to: