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

MPI implementations in squeeze



With the recent upload of MPICH2, we now have four separate MPI implementations
in the archive: two with active upstreams and maintainers (MPICH2, OpenMPI) and
two on terminal life support (MPICH, LAM).

There's been some preliminary discussion before about dropping the latter two
[1], though legacy support is an issue as well [2].  Currently, the MPI
situation is fairly messy: 18 source packages depend on mpi-default-dev
(OpenMPI or LAM, depending on architecture), but another 18 depend on various
permutations of the implementations directly [3], with no particular
consistency.

>From a package maintainer standpoint, I'd like to see us start reducing the
number of implementations to build client packages against, even if we maintain
all the MPI implementations themselves (perhaps moving them to the 'oldlibs'
section).  What I'm wondering is:

 * in mpi-defaults, should MPICH2 replace LAM for architectures not supported
   by OpenMPI?
 * should we start filing wishlist bugs asking packagers not to build against
   MPICH (1) and LAM?
 * is it too late in the release cycle to propose this as a release goal?
   should squeeze+1 be the target instead?  squeeze+2?

This is orthogonal to solving #552429, which will need action before the
squeeze release in any case.


-- 
Nicholas Breen
nbreen@ofb.net


[1] http://lists.debian.org/debian-science/2009/06/msg00029.html
[2] http://lists.debian.org/debian-science/2009/06/msg00039.html
[3] build-deps on:      lam4-dev        libmpich1.0-dev libopenmpi-dev
      apbs              no              yes             yes
      clustalw-mpi      yes             no              yes
      ecs               no              no              yes
      fftw              no              yes             no
      gromacs           yes             yes             yes
      hpcc              no              no              yes
      hdf5              yes             yes             yes
      meep              no              yes             no
      mpb               no              yes             no
      music             no              no              yes
      netpipe           yes             yes             no
      python-scientific yes             yes             no
      regina-normal     no              yes             no
      tessa             yes             no              no
      tree-puzzle       yes             no              no
      trilinos          no              no              yes
      xmds              no              yes             no
      xmpi              yes             no              no


Reply to: