mpich C++ translation (to the correct list)

[Russ Allbery <rra@stanford.edu>]

Hello all,

I've volunteered to try to help coordinate the mpich C++ transition.  I'm
still just learning how to do this, so this first message is just an
outline of what I think the current state is and what actions are needed
next so that more experienced people can correct me if I get any of it
wrong.

apt-cache rdepends (is there a better tool?) turns up the following binary
packages depending on libmpich1.0 or libmpich-mpd1.0 that are not part of
the mpich package itself (source packages in parentheses):

  blacs-mpich-test  (blacs-mpi)
  illuminator-demo  (illuminator)
  libluminate5      (illuminator)
  libluminate6      (illuminator)
  libparmetis3.1    (parmetis)
  netpipe-mpich     (netpipe)
  scalapack1-mpich  (scalapack)

Note that libluminate5 is only in testing and libluminate6 is only in
unstable since illuminator did an SONAME change with 0.9.0-1, but
thankfully it looks like there are no other dependencies on those
libraries to complicate matters.

illuminator also depends on libpetsc2.2.0 which depends on libmpich1.0,
but petsc has already done its own transition, so it's ready to go.
Thankfully, it looks like libluminate6 and libparmetis3.1 are not
themselves written in C++ and therefore don't need a separate transition,
just a rebuild against the newer library.

So, at first glance it looks like blacs-mpi, illuminator, parmetis,
netpipe, and scalapack all need to be rebuilt against libmpich1.0c2, and
then all of those packages, mpich, and petsc can all go into testing
together.  There are, however, a few holdups:

 * illuminator currently FTBFS on sparc with the following error:

   ldd: /lib/ld-linux.so.2 exited with unknown exit code (132)
   dpkg-shlibdeps: failure: ldd on `debian/illuminator-demo/usr/bin/tsview-ng' gave error exit status 1
   dh_shlibdeps: command returned error code 256

   This error has persisted through a couple of attempted builds but
   doesn't occur on any other platforms, which makes me think that it's a
   toolchain problem of some sort.

 * blacs-mpi FTBFS on m68k the last time it was built, but looking at the
   build log this looks like a buildd failure rather than any problem with
   the package.  That means that the new upload to build against the
   current mpich library should be fine.

 * netpipe currently build-depends (and netpipe-mpich currently depends)
   on mpich, a package that's been dropped from the current mpich package.
   My guess is that this is supposed to be mpich-bin, libmpich1.0-dev
   (although I need to take a closer look).  This is Bug#323744.

The illuminator problem is the only one that really looks worrisome.  We
may need some help on SPARC to track that one down.

So, here's what I believe the next steps to be:

 * Mail the maintainers of blacs-mpi, netpipe, and scalapack and make sure
   that they know that their packages need new uploads to build against
   the new mpich libraries.  illuminator and parmetis are maintained by
   the mpich maintainer, who already knows this.  :)

 * Check into the netpipe situation and follow up to Bug#323744 with the
   appropriate patch for debian/control based on what the package really
   needs to build and run.

 * Follow up on the illuminator FTBFS problem on SPARC.

Since this is the first time that I've done this, I'd appreciate it if
someone could check me on my reasoning.  If this sounds good, I can start
with those steps tomorrow.

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>