Hello,<br><br><div class="gmail_quote">2012/2/21 Adam C Powell IV <span dir="ltr"><<a href="mailto:hazelsct@debian.org">hazelsct@debian.org</a>></span><br><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
tags 660241 moreinfo<br>
thanks<br>
<br>
Hello,<br>
<div class="im"><br>
On Fri, 2012-02-17 at 09:37 -0600, Edscott Wilson Garcia wrote:<br>
> Package: libhypre-2.4.0<br>
> Version: 2.4.0b-7<br>
> Severity: important<br>
><br>
><br>
> Hypre works fine with mpich2. Instalation via debian package invariably ties<br>
> it up with openmpi. When target user has a preference for mpich2 (or a specific<br>
> need for mpich2), the libhypre debian package is no good. Package should be<br>
> constructed in the manner of libhdf5, which provides the virtual package libhdf5 from<br>
> both libhdf5-openmpi.deb and libhdf5-mpich2.deb.<br>
<br>
</div>Please be more specific: exactly how is the libhypre package "no good"<br>
with mpich2?  Looking at the Buildd on sparc, for example, it builds<br>
just fine using mpich2, and lots of other reverse-depends (petsc, slepc,<br>
elmerfem, etc.) build just fine too.<br></blockquote><div><br>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.<br>
<br>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). <br>
<br>If there were separate binary packages for openmpi/mpich2 (as with the hdf5 binary package), the debian stable platform would remain very attractive.<br> </div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

<br>
The purpose of mpi-defaults is that we compile each package only once<br>
using the MPI implementation relevant for that platform.  This cuts the<br>
archive disk bloat and build time in half, or sometimes better -- by a<br>
factor of 4 if HDF5 would adopt this method, since they still build with<br>
deprecated mpich and lam.<br></blockquote><div><br>Sure, mpich and lam are deprecated, but the issue here is mpich2, which is definitely not deprecated. <br> </div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

<br>
If there is no particular reason for separating this into different<br>
packages, I'm going to downgrade this to wishlist and tag it "wontfix".<br>
<div class="im"><br></div></blockquote><div><br>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.<br>
<br>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. <br> <br>
</div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="im">
<br>
<br>
</div>You're on amd64, so why are you concerned about hypre on non-OpenMPI<br>
platforms?<br>
<span class="HOEnZb"><font color="#888888"><br></font></span></blockquote><div><br>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.<br>
<br>I appreciate your time and response, and will be grateful if you weigh my point of view.<br><br>Edscott </div><br></div><br>