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

[Adam C Powell IV]

severity 660241 wishlist
tags 660241 -moreinfo
thanks

Hello,

First, sorry about the tone of that last post, I think it was somewhat
condescending and rude, and that was inappropriate regardless of where
we end up.

On Tue, 2012-02-21 at 11:10 -0600, edscott wilson wrote:
> 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.

I think I understand your concern.  But since the entire Debian
downstream, including the packages I mentioned in the previous email,
will all use OpenMPI, from a Debian user's point of view, there's not
much point in having the entire archive double-built with mpich as well.

>         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. 

Right, my point there is that mpich2/openmpi is similar duplication to
the mpich2/openmpi/mpich/lam duplication of HDF5 just somewhat less so.

>         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.

Well, that depends on your perspective.  We have to balance the interest
of a small group of users who want the whole system to be built against
multiple MPI implementations, vs. the vast majority who will be using
Debian packages linked to other Debian packages and don't care about the
middleware.  If I'm just using Elmer or FreeCAD or gmsh, I don't care
what the MPI implementation is.

And if that vast majority lets us cut the build servers' time in half,
and the archive space in half, well you can see where this is going.

> 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.

If you like I can put instructions for how to build with mpich2 in a
README file.  But I'm sorry to say I lean against rebuilding this whole
package twice on every single architecture when it isn't necessary for
the vast majority of users, and we have spent lots of hours discussing
and building the entire mpi-defaults system specifically for the purpose
of avoiding the duplication.

>         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.

Sorry, that was based on a misunderstanding of your original bug
wording, in which I thought you were saying the mpich2 library is "bad"
for some reason.

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

No problem.  Let me know if you want me to put instructions for other
MPI implementations in a README file.

I've done this for PETSc, and went so far as to use the Debian
alternatives mechanism to enable the user to install multiple PETSc
packages with different non-standard MPI implementations, and switch
between them on the fly.

-Adam
-- 
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

Engineering consulting with open source tools
http://www.opennovation.com/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part
URL: <http://lists.alioth.debian.org/pipermail/debian-science-maintainers/attachments/20120221/52c9a195/attachment.pgp>