Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.

Bug 225979

Summary: Merge Review: lam
Product: [Fedora] Fedora Reporter: Nobody's working on this, feel free to take it <nobody>
Component: Package ReviewAssignee: Ed Hill <ed>
Status: CLOSED NOTABUG QA Contact: Fedora Package Reviews List <fedora-package-review>
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: bugs.michael, dledford, susi.lehtola
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-01-20 23:30:43 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On: 473593    
Bug Blocks:    

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

http://cvs.fedora.redhat.com/viewcvs/devel/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:

  http://www.lam-mpi.org/

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:

good:
 + 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:

http://fedoraproject.org/wiki/Packaging/Guidelines#Legal

   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:
http://linux.dell.com/files/fedora/FixBuildRequires/mock-results-core/i386/lam-7.1.2-8.fc7.src.rpm/result/rpmlint.log
   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.