[Pkg-openmpi-maintainers] Request to Join Project Debian OpenMPI Team

[Dirk Eddelbuettel]

On 15 June 2007 at 19:26, Tilman Koschnick wrote:
| On Fri, 2007-06-15 at 11:29 -0500, Dirk Eddelbuettel wrote:
| > On 15 June 2007 at 18:16, oliva.g at na.icar.cnr.it wrote:
| > | I Agree. We need to carefully check if the package can cohoexist with
| > | the other MPI libraries. I think we should include among these the new
| > 
| > Yes indeed. At a minimum all run-times needs to be installable at the same
| > time.  As for -dev packages, I haven't thought hard about this, but it would
| > be need if one could have more than one too.  Longer term goal, maybe?
| 
| The alternative system works very well when there is a one-to-one
| mapping between two packages, for example a single binary as master and
| the corresponding man page as slave.
| 
| The problem with the different MPI implementations is that every package
| seems to have another set of files under update-alternatives' control,
| and within these sets use another master link. Examples are mpiexec,
| mpirun, mpicc, mpi.h etc. Then there are differnt ways to split these
| files up - everything under the control of a single master, or compile
| time and runtime files separately? 
| 
| I had problems in the past with differing numbers of slave links as
| well. Say package A has mpirun as master and mpirun.1.gz as slave.
| Package B only has mpirun as master and no man page. IIRC, if A is
| active first and then replaced by B, mpirun points to B, mpirun.1.gz
| still to A. Once both packages are removed, mpirun.1.gz remains behind
| as a dangling symlink.
| 
| So, the one thing we should definitely discuss with the maintainers of
| other MPI implementations is the whole alternatives handling in detail,
| and not just the priorities to choose. 

Fully agreed!

| > | mpich2 package wich is currently mainteined here:
| > | http://torvalds.cs.mtsu.edu/~zach/debian/1.0.2p1
| > | by Zach Lowry <zach at zachlowry.net>.
| > | What do you think?
| > 
| > Yes. I had a brief look at MPICH2 as a coworker though the could use it from
| > windows. He gave up on that idea, and I am happy with lam for the status quo
| > and openmpi as the future, broadly speaking :), but we should coexist nicely
| > with the other MPIs.
| 
| Since Zach lost interest quite a while ago, and didn't reply to my last
| pings, I continued with his packages for my own inhouse use. I never got
| to the stage where I could ask for an upload, though, and have switched
| to OpenMPI in the meantime. If anyone is interested in more recent -
| albeit a bit quick and dirty - MPICH2 packages, I can make them
| available.

Ohhh you're right. I forgot that part. My local ones were also a hack based
off Zach's stuff but I am not pushing that any further.

Dirk
 
| I think MPICH2 is the one major implementation that didn't join the
| OpenMPI group - is that right? So it might very well stay around,
| whereas I think MPICH will be replaced by MPICH2 eventually, and LAM by
| OpenMPI.
| 
| Cheers, Til
| 

-- 
Hell, there are no rules here - we're trying to accomplish something. 
                                                  -- Thomas A. Edison