Re: Mpich 1/2/3

[Yvan Fournier <yvan.fournier@free.fr>]

Hello,

As a recent subscriber to Debian Science, but a long-time developer of
the Code_Saturne CFD code (which is packaged in Debian by Sylvestre
Ledru, using OpenMPI, but which can also be compiled with MPICH2 or
MPICH-3), I would be quite happy to see obsolete MPI packages go (MPICH1
and LAM-MPI) go away in modern Linux distributions.

Long version (rant against keeping MPICH1 and LAM in case anybody would
suggest this):

>From a perspective of compiling a current version of a code on a Debian
or Debian-based distribution, MPI packaging is complex enough, as at
least OpenMPI and MPICH2-3 are possible choices, and depending on
whether one of the two or both are installed, and whether the
mpi-defaults package was installed, detection of MPI libaries in
autoconf scripts using classical "--with-mpi=<prefix>" is not always
sufficient, and finer control (--with-mpi-lib, --with-mpi-includes, ...)
may be needed, which is a pain (wrappers such as mpicc always work, but
using them leads to other constraints, such as having one MPI build per
compiler version). In addition, MPI libraries may be a dependency of
other packages such as HDF5, which are themselves dependencies of many
scientific codes.

>From a perspective of compiling a current version of a code on a Debian
or Debian-based distribution, MPI packaging is complex enough with
OpenMPI and MPICH2-3, as depending on whether one or both are installed,
and whether the mpi-defaults package was installed, detection of MPI
libaries in autoconf scripts using classical "--with-mpi=<prefix>" is
not always sufficient, and finer control (--with-mpi-lib,
--with-mpi-includes, ...) may be needed, which is a pain (wrappers such
as mpicc always work, but I am not too fond of them, as using them leads
to other constraints, such as having one MPI build per compiler suite
version, and if every odd library required compiler wrappers, combining
them would be a nightmare).

In addition, MPI libraries may be a dependency of other packages such as
HDF5, which are themselves dependencies of many scientific codes.
So adding further combinations with obsolete packages only makes things
worse.

MPICH1 and LAM-MPI lack quite a few MPI-2 (and obviously, MPI-3)
features available in their successors (MPICH2, now MPICH-3) and OpenMPI
respectively), and have basically unmaintained for more than 5 years, so
having them removed from Linux distributions will help avoiding the risk
of having a user compile a current code using MPI with an obsolete MPI
library.

Finally, using the same naming policy as the MPICH developpers
themselves (referring to the old MPICH as MPICH1, and renaming MPICH2 to
MPICH when they upgraded to version 3) seems like a sane thing to do,
and again, the best way to avoid confusion.

Regards,

	Yvan

Sunday 26 mai 2013 at 20:24 +0200, Torquil Macdonald Sørensen wrote:
> Hi!
> 
> I am a maintainer of the "mpich2" package. My goal is to package Mpich 
> 3.0.4 and get someone from the Debian Science team to upload it to Sid. 
> Before Lucas Nussbaum stepped down as a maintainer, we decided that it 
> would be a good idea to change the source package name from "mpich2" to 
> "mpich" at the same time.
> 
> A source package called "mpich" already exists, but the software is very 
> old and I don't really see the usefulness of it anymore. Perhaps I am 
> wrong?  I contacted the maintainers of "mpich" to ask, but did not get a 
> response. Therefore I'm asking the Debian Science team.
> 
> Do you guys think the old "mpich" source package can be removed from Sid 
> and Testing? I have checked the rdepends of all its associated binary 
> packages. The only instance of an non-mpich package referring to a 
> binary package from the "mpich" source is the package 
> "science-nanoscale-physics", which only suggests libmpich1.0gf.
> 
> Mpich 3 is a much improved version of this software, so perhaps the old 
> mpich source package can be eliminated, so I can go ahead and work on 
> renaming the current mpich2 to mpich, and upgrade it to the newest 
> upstream Mpich version 3.0.4?
> 
> Best regards
> Torquil Sørensen
> 
>