Fedora Merge Review: lam http://cvs.fedora.redhat.com/viewcvs/devel/lam/ Initial Owner: dledford
Do we still actually want to keep lam around? I thought it had been essentially replaced in Fedora by another MPI implementation.
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.
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.
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.
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.
Well this can be closed since lam has been dropped from Fedora a long time ago already.