A disclaimer: I'm no more a MPI user currently, so take my opinions with a grain of salt.
On Sat, Mar 14, 2009 at 04:56:41PM +0100, Manuel Prinz wrote: > Am Samstag, den 14.03.2009, 10:54 +0100 schrieb Francesco P. Lovergine: > > while working on HDF5 I'm considering to move MPI support to use > > mpi-default-dev > > and mpi-default-bin. That would imply providing a single reference platform > > support > > (openmpi or lam, completely dropping mpich AFAIK) which is quite different > > from what > > done until today. I wonder if it would be appropriate having instead a > > mpi-all-dev and > > mpi-any-bin package which depends on all supported platforms > > on every archs. That would allow transparently building lam, mpich and > > openmpi > > flavors whenever possible, and depending on any appropriate tool the admin > > would install. > > That is probably the goal to go for but there are some technical > problems with it. Most debian/rules can't easily include a snippet and > finally do the right thing. > > There are also some other issues: Most MPI implementations do not play > well together, meaning there currently are problems if two or more are > installed. (Yes, there shouldn't be, but it's an unresolved issue as of > now.) Also, LAM/MPI can be considered to be dead upstream and is not > recommended for usage, I think Debian should not build against it > anymore; ...which is not mpi-default is doing now, because the choice is OpenMPI vs LAM, indeed. I wonder if non-LAM can be a viable choice for all archs anyway. I have not information about that. But for that I think all admins use just one implementation for their whole cluster, the problem is not having the missing one to install :-) That was my motivation to discuss the use of the 'preferred' one instead of any of the available ones. > there's nothing against still providing the libraries, of > course. Also, MPICH is superseeded by MPICH2 which noone ever packaged. > I do not know the details but as I check last, MPICH2 seems to not have > support for modern inter-conntects. They are supported via forks, so one > would have to package a MPICH2 version for each interconnect. > Therefore, it seems to me appropriate having only OpenMpi and Mpich2 implementations for the future. Both them to be verified per each arch. > Mpi-defaults was supposed to support package who need MPI support, and > give it to them in an easy way. I was not designed to be a full-blown > solution. it definitely worth for such a solution but several questions > need to be addressed first. I do maintain a list of issues that in my > opinion need to be resolved first. I need to write it up in a better way > and have it discussed here and in pkg-scicomp first. Also, we should > check if we really want so many (and out-dated) MPI versions in Debian, > of if we can go with one for the apps and provide libs for all others. > If MPI were to be standardized on ABI compatibility, that resolve the > whole issue. But since this is not going to happen anytime soon, we have > to work on a solution that works for us. > > I really welcome your idea and would be glad to hear suggestions if you > have an idea of how to implement that! I also hope we can have the > discussion about MPI in Debian soon; but I currently have to spend the > time to fix "my" MPI implementation before I can write up a proposal. > > Best regards > Manuel On this basis, I think that it would be the case to hold on any re-implementation of the MPI related packaging for HDF5. It is much better defining a decent policy draft before proceeding with modifying packages here and there. -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
