This has been an interesting discussion to follow. Here are my thoughts
on the RPM packaging...
On 6/16/05, Jeff Squyres <jsquyres_at_[hidden]> wrote:
> We've also got the "announce" mailing list -- a low volume list just
> for announcing new releases (and *exciting* messages about products you
> might be interested in... just kidding.).
> We actually got a lot of help in this area from Greg Kurtzer from LBL
> (of cAos/Warewulf/Centos fame). He helped us a bunch with our
> [previously extremely lame] LAM/MPI .spec file, and then offered to
> write one for Open MPI (which he did about a month or two ago).
> I have some random user questions about RPMs, though:
> 1. Would you prefer an all-in-one Open MPI RPM, or would you prefer
> multiple RPMs (e.g., openmpi-doc, openmpi-devel, openmpi-runtime,
I prefer split RPMs. The fingrained split you mention works well for
thin/diskless-nodes, but a simple split of runtime vs everything-else
would be "good enough". The primary problem with an all-in-one RPM
would be the footprint of the non-MPI packages that satisfy MPI's
dependence tree, especially the compilers.
> 2. We're definitely going to provide an SRPM suitable for "rpmbuild
> --rebuild". However, we're not 100% sure that it's worthwhile to
> provide binary RPMs because everyone's cluster/development systems seem
> to be "one off" from standard Linux distros. Do you want a binary
> RPM(s)? If so, for which distros? (this is one area where vendors
> tend to have dramatically different views than academics/researchers)
If you supply fairly clean SRPMs, I think the distros themselves can
do the binary RPM building themselves. At least that is easy enough
for cAos to do. I guess the problem lies in the disparity in the distribution
release cycle and Open MPI's expected release cycle. Certain RedHat
distribution versions shipped with amazingly old versions of LAM/MPI,
which I recall caused no end of trouble on the LAM/MPI mailing lists
with questions from long-ago fixed bugs. How much is it worth to
the Open MPI team to be able to answer those questions with:
rpm -Uvh http://open-mpi.org/..../open-mpi-1.0-fixed.x86_64.rpm
rather than having to explain how to do "rpmbuild --rebuild".
I'll suggest that eventually you will want binary RPMs for SUSE 9.3 and
CentOS 4 and/or Scientific Linux 4 in both i386 & x86_64 flavors.
I'm sure you will get demand for a lot of Fedora Core flavors, but I think
that road leads to madness... I think it might work out better to try and
get Open MPI into Dag Wieers RPM/APT/YUM repositories... see:
or the still-under-construction RPMforge site:
That's more than my two cents...
Tim Mattox - tmattox_at_[hidden]
I'm a bright... http://www.the-brights.net/