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 nbr...@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 -- To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org