First of all: Thanks, Nicholas, for bringing it up and providing the
very helpful information!
> 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.
Am Dienstag, den 10.11.2009, 09:19 -0500 schrieb Adam C Powell IV:
> 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.
I also think that mpi-defaults was a step in the right direction which
we should continue.
> > >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.
This might make sense. It's confusing that we have different
implementations on these platforms anyway, so having just supported
implementations seems like a plus to me.
> > * 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.
This would help to bring the issue forward. I support this and offer
help where needed. But we should think of some preconditions before we
go with that. From the top of my head, these things need to be done:
* Modify mpi-defaults to use MPICH2 on arches that are not
supported by Open MPI (yet). This requires a rebuild of all
dependant packages and needs to be coordinated with RM.
* Bugs should be filed against all packages using the "obsolete"
MPI implementations (LAM and MPICH1), requesting to drop the
B-D. Severity minor or wishlist seem appropriate.
* We should discuss whether or not we want to build packages
against both MPI implementations or just mpi-defaults. Of course
it is up to the maintainer to support as many implementations as
time permits but I can imagine that users do not really care.
They want to run an application in parallel, don't they? (I
seriously don't know. Both approaches have their advantages.)
* Alternatives need to be fixed. Besides what the bugs that
Nicholas referenced say, there are two other issues with those:
First, the priorities do not match the reality (Open MPI being
the default / recommended implementation to use), and second,
that mpi.so is also in the alternatives, which is wrong in every
respect and has bother me for a very long time now. The
implementations are not ABI-compatible in any way, and we really
need to get rid of that. I have to check what needs to be done
and if rebuilds are needed more closely. I will comment on the
BTS on that.
The next steps pretty much depends on the answer to the question if we
want to support packages build against Open MPI and MPICH2 or just
recommend using mpi-defaults. Both have advantages, both have drawbacks.
And if we go for the first option, what is the correct behavior? Should
the packages conflict with each other or should they conflict with the
other library? Or should the be build in a way so that they can be
switched via alternatives as well? I have no idea what is reasonable,
but if we support more than one MPI implementation, we have should solve
that issue as well. The current practise is that every maintainer
decides what's best, and it's far from being ideal, IMHO. Don't get me
wrong: I do not think that maintainers did a bad job, quite the
opposite, but I think we now have the chance to fix structures that just
grew into what is the current situation, and that are in real need to be
fixed.
> > * 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.
As you said in your other mail, with the release date being somewhere in
the next year, this should be doable. If it's too late for a release
goal, we can make it an internal release goal. Arguments for that change
are reasonable and I guess that there is support on the maintainer side,
even if we can't make the bugs to be filed RC.
> > 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.
This will be the first thing to fix, along with the library issue I
mentioned above. I'll start with that just now. ;)
Best regards
Manuel
Attachment:
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil