[Bug 171993] Review Request: mpich2 - An implementation of MPI

bugzilla at redhat.com bugzilla at redhat.com
Wed Apr 16 22:48:45 UTC 2008


Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug report.

Summary: Review Request: mpich2 -  An implementation of MPI


https://bugzilla.redhat.com/show_bug.cgi?id=171993





------- Additional Comments From dledford at redhat.com  2008-04-16 18:48 EST -------
(In reply to comment #70)
> > Also of note is that, in line with the comments in comment #7 and comment #8, my
> > current packages use %{_libdir}/%{name} as the prefix for all files in the lam
> > package, and %{_libdir}/%{name}/%{version}-%{opt_cc} as the prefix for all files
> 
> Do you actually ship openmpi with multiple versions and compilers on RHEL?

With multiple compilers, no, and I never will.  It's there as a convenience item
for those people that want to build their own version with a different compiler.
 Although, in order to have both the mainline and another compiler version
installed at the same time they should really add the %{opt_cc} marker into
Name: as well (I didn't do that for gcc since I consider that the default).

> I saw
> your use of the %{opt_cc} sometimes ago and copied it for mpich2, but I don't
> think its necessary for Fedora builds, as one can build with gcc and we can only
> carry a version at a time.

We can only carry a version at a time in the repo, but that doesn't mean that a
user can't configure yum/rpm to treat openmpi as an installonly item (like the
kernel).  Since I've had people tell me they need the ability to install
specific versions for certain certified apps, but also want the most up to date
version for their own apps, that's the rationale behind keeping the version tag
in the directory path for the prefix.

> I believe the second option in comment #7 (which is
> what I'm using now) works fine for the multilib situation, which is farthest
> multiple instance Fedora can allow now.  
> 
> > in openmpi (the difference being because I've never been given any requests to
> > have more than one version or compiler of lam installed at a time, but I have
> > been given requests to have multiple versions and multipler compilers of openmpi
> > at the same time).
> > 
> > Another item of note is that I have outstanding requests to also include
> > mvapich/mvapich2 in the distro for use over infiniband.  I've not gotten any
> > requests for mpich, but then I'm not fully aware of the relationship between
> > mpich and mvapich.
> 
> mvapich is one of several other projects that are built on top of mpich2. There
> is no reason why it can be packaged/shipped independently of mpich2.

Well, that wasn't really my point. My question was, assuming you have
mvapich/mvapich2 available in fedora, then do we need mpich/mpich2?  Is there
any compelling reason for it?  (Not that I object if you want to do the work,
just asking)

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.




More information about the package-review mailing list