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: