Bug#660241: libhypre-2.4.0: should be two packages: libhypre-openmpi and libhypre-mpich2

[edscott wilson]

Hello,

2012/2/21 Adam C Powell IV <hazelsct at debian.org>

> tags 660241 moreinfo
> thanks
>
> Hello,
>
> On Fri, 2012-02-17 at 09:37 -0600, Edscott Wilson Garcia wrote:
> > Package: libhypre-2.4.0
> > Version: 2.4.0b-7
> > Severity: important
> >
> >
> > Hypre works fine with mpich2. Instalation via debian package invariably
> ties
> > it up with openmpi. When target user has a preference for mpich2 (or a
> specific
> > need for mpich2), the libhypre debian package is no good. Package should
> be
> > constructed in the manner of libhdf5, which provides the virtual package
> libhdf5 from
> > both libhdf5-openmpi.deb and libhdf5-mpich2.deb.
>
> Please be more specific: exactly how is the libhypre package "no good"
> with mpich2?  Looking at the Buildd on sparc, for example, it builds
> just fine using mpich2, and lots of other reverse-depends (petsc, slepc,
> elmerfem, etc.) build just fine too.
>

Exactly. hypre builds without problems with mpich2. That's precisely my
point. What I have my finger on is on the user end, not the developer who
has no problem building hypre however. Let me clarify this with an example.
Say you have a group of developers who are developing an oil reservoir
simulation program  based on hypre. These developers may or may not be
using a debian distro. Once the software is finished, it will be installed
on computers belonging to petroleum engineers with little knowledge as to
the inner working of the simulator. The intended platform is debian stable,
on amd64/i386, because it is a good linux distribution for this user
profile.

The simulation software may not have hypre linked in statically (so say the
lawyers of the oil company) and must be linked dynamically with the system
installed hypre. This has to be installed from a debian binary package. The
current debian binary package requires openmpi.  But there might be another
package on the users computer that uses mpich2 (say some parallel hdf5
software).

If there were separate binary packages for openmpi/mpich2 (as with the hdf5
binary package), the debian stable platform would remain very attractive.


>
> The purpose of mpi-defaults is that we compile each package only once
> using the MPI implementation relevant for that platform.  This cuts the
> archive disk bloat and build time in half, or sometimes better -- by a
> factor of 4 if HDF5 would adopt this method, since they still build with
> deprecated mpich and lam.
>

Sure, mpich and lam are deprecated, but the issue here is mpich2, which is
definitely not deprecated.


>
> If there is no particular reason for separating this into different
> packages, I'm going to downgrade this to wishlist and tag it "wontfix".
>
>
There is a particular reason, as exposed before. I do have an important
user base down the road that will need to use hypre and need to be able to
choose between  either openmpi or mpich2. These users should *not* be
required to build hypre.

If you tag the bug as "wontfix", then I'll  have to go ahead and build the
debian packages and publish them on sourceforge. Another debian developer
suggested I file a bug report before doing this.


>
>
> You're on amd64, so why are you concerned about hypre on non-OpenMPI
> platforms?
>
>
The software I'm concerned with is not for me. I always compile from
source. My concern is for others in a effort to make things more robust.

I appreciate your time and response, and will be grateful if you weigh my
point of view.

Edscott
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/debian-science-maintainers/attachments/20120221/519656f6/attachment.html>