Here are my opinions for what they're worth... On Mon, 2009-11-09 at 16:47 -0800, Nicholas Breen wrote: > 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. The concerns you raise are the motivation for mpi-defaults. And IMO 50% voluntary transition there with no particular push or strong impetus is pretty good progress. > >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? I think that would make a lot of sense since LAM is end-of-life. > * should we start filing wishlist bugs asking packagers not to build against > MPICH (1) and LAM? I've done this for packages I care about, and posted patches, and done NMUs (with maintainer approval). So I'd say go for it. > * is it too late in the release cycle to propose this as a release goal? > should squeeze+1 be the target instead? squeeze+2? I think it's too late for squeeze, but squeeze+1 should definitely be doable. > This is orthogonal to solving #552429, which will need action before the > squeeze release in any case. Indeed. And while we're at it, given the popularity of fortran, we need a consistent fortran library alternatives link as a slave of mpi... Will add that to the bug. -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/
Attachment:
signature.asc
Description: This is a digitally signed message part