Re: MPI implementations in squeeze
I understand the final state of the modern Debian infrastructure for MPI
is now in place (modulo the questions around deprecating MPICH and LAM).
That is, the disruptive Open MPI transition is now complete, correct?
>From the point of view of a client package, what is now best practice
for working with MPI? Is there a website/wiki/document explaining how
to set up an MPI-using package, or is it just a matter of RTFM from
mpi-default-dev?
For context, gerris includes MPI support which is currently switched
off. I would like to create an additional gerris-mpi package which has
MPI switched on.
Thanks,
Drew
On Mon, 2009-11-09 at 16:47 -0800, Nicholas Breen wrote:
> 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.
>
Reply to: