Bug 225979 - Merge Review: lam
Summary: Merge Review: lam
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Ed Hill
QA Contact: Fedora Package Reviews List
Depends On: 473593
TreeView+ depends on / blocked
Reported: 2007-01-31 19:17 UTC by Nobody's working on this, feel free to take it
Modified: 2011-01-20 23:30 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2011-01-20 23:30:43 UTC
Type: ---

Attachments (Terms of Use)

Description Nobody's working on this, feel free to take it 2007-01-31 19:17:23 UTC
Fedora Merge Review: lam

Initial Owner: dledford@redhat.com

Comment 1 Jason Tibbitts 2007-02-04 04:49:58 UTC
Do we still actually want to keep lam around?  I thought it had been essentially
replaced in Fedora by another MPI implementation.

Comment 2 Ed Hill 2007-02-04 22:34:10 UTC
I think Jason is on the right track here.  LAM is old and all of the LAM 
upstream has joined forces with OpenMPI:


If folks do want to keep LAM around (which is understandable since it is 
a known quantity, after all), then its high time to clean it up so that 
its easier to simultaneously install multiple MPI implementations.

Comment 3 Ed Hill 2007-02-05 03:54:18 UTC
Please ignore (and, if possible, excuse) comment #2.  I've read through 
both the LAM and OpenMPI spec files and quite a bit has happened in the 
past 6+ months.  Here is the start of a more thorough review--I'm just 
too tired to continue tonight and will post what I have so far:

 + license is good and correctly included
 + spec file is not needlessly complicated (!)
 + proper handling of ldconfig

standing on a soap-box preaching to... somebody, hopefully:
 + I applaud the folks who put the time and effort into making 
   LAM and OpenMPI work with (and hopefully, without) the 
   "alternatives" system.  Unfortunately, I think its the wrong
   way to solve the problem.  Unlike the selection of an MTA, 
   the selection of an MPI system is NOT (and should NOT!) be 
   treated as a system-wide affair.  In an ideal world, users 
   should be able to effortlessly switch between different 
   MPI implementations at any time.  For different MPI 
   implementations, using something like the "environment 
   modules" approach makes a *LOT* more sense than the 
   "alternatives" system (which is geared towards programs
   which are much more system-wide and much less able to 
   work independently and simultaneously).

needswork or "please help me understand this":
 - Source should match upstream.  It appears that the only 
   differences between the supplied '7.1.2-rh1' tarball and 
   the upstream '7.1.2' is the removal of some code covered
   by the APPLE PUBLIC SOURCE LICENSE v2 which, according to:


   is OK to include in Fedora.  But perhaps there are some 
   more complicated linkage issues that necessitate its 
   removal...?  Could you please explain.

 - rpmlint output is available at:
   and most of it seems to be cosmetic (e.g. the trailing '.' and the 
   macro-in-changelog entries).  However, the dangling-relative-symlink
   warning does seem worrisome.

Comment 4 Doug Ledford 2007-02-05 05:32:11 UTC
In regards to dropping LAM, I'm all for it (and I currently own it).

In regards to the system wide default issue.  Although the LAM and OpenMPI
packages attempt to set the system wide default via alternatives, that's really
only for people that want to be lazy and just use whatever is there.  The
purpose of the /usr/share/{lam,openmpi}-<version>/bin* directories is so that
people can still run their preferred application without it being the system
wide default (openmpi in particular needs to be called with $0 being a correct
filename or else it won't find the right modules, so you can't just create
unique symlinks to the binaries).  If people want the alternatives stuff removed
strongly enough, then I could just make all the mpi implementations use
non-default locations and do away with the overlap entirely, although I suspect
that would violate the linux FHS, so the justification would need to be strong
enough to do so.

As for the source not including the APSL files, I was informed (by legal) that
the exact wording of the APSL makes it questionable whether or not it is
actually legal to have both APSL and GPL source distributed in the same tarball,
and so I removed the APSL files from the tarball we ship at their request.  I
don't really know enough about the legal stuff to comment on whether or not
that's right, so I can't argue the correctness of the action, I was just doing
what I was told (however, I was told this in regards to RHEL, not Fedora, so it
may have been an incorrect assumption on my part that the same legal issue would
exist in Fedora).

As for the dangling symlink issue, that's from the practice of putting only
versioned .so files in -libs (aka, totalview.so.0.0.0 and totalview.so.0) and
putting the bare .so file in -devel.  The -devel package should have a Requires:
on the -libs package, which would negate the dangling symlink (pauses to go
check)...indeed, the base package Requires: -libs, and -devel Requires: the base
package, so the dependency chain is in fact in tact, rpmlint just gave a false
positive in this case.

Comment 5 Doug Ledford 2007-05-17 19:47:58 UTC
A newer version of lam that corrects a problem in the lam.pc and lam.module
files has been built.  A few other tidy-ups happened as well.

As for the use of the alternatives system, I'm currently working with upstream
for openmpi and mvapich to work out a system that is acceptable to both of them.
 Once that system is finalized, I'll update lam to match.  And, I agree, the
alternatives method, while usable, is not really optimal for mpi stacks.

Comment 6 Susi Lehtola 2011-01-20 23:30:43 UTC
Well this can be closed since lam has been dropped from Fedora a long time ago already.

Note You need to log in before you can comment on or make changes to this bug.