Currently the rawhide branch of Boost only builds against MPICH2, and ships the MPICH2 libraries in %{_libdir}. This is a violation of the MPI Packaging Guidelines http://fedoraproject.org/wiki/PackagingDrafts/MPI that have been approved by FESCo in August http://meetbot.fedoraproject.org/fedora-meeting/2009-08-14/fedora-meeting.2009-08-14-17.01.html The package compiled against MPICH2 must be named -mpich2, not -mpi. Same thing with the python modules. Note that the MPICH2 package has been broken on the account of the python sitedir for months, and the maintainer has not responded to the bugs. MPICH2 also still blatantly violates the guidelines by providing alternatives support, thus making itself available by default, which explains why you have been able to build without explicitly loading MPI support in the spec file with %{_mpich2_load}. In addition, http://fedoraproject.org/wiki/PackagingDrafts/MPI#Packaging_of_MPI_software "If possible, the packager MUST package versions for each MPI compiler in Fedora (e.g. if something can only be built with mpich2 and mvapich2, then lam and openmpi packages do not need to be made)." so you really should build also a package against Open MPI, as it is really the traditional MPI runtime on Fedora and is a *lot* easier to setup on a shared memory computer than MPICH2.
Frankly no-one of us had any idea that anything like "MPI packaging guidelines" existed. I'll look into porting the package to follow the policy.
(In reply to comment #1) > Frankly no-one of us had any idea that anything like "MPI packaging guidelines" > existed. This is partly the FPC's fault, since the guidelines have been sitting, approved, without being integrated with the existing guidelines. > I'll look into porting the package to follow the policy. OK. Give me a holler if something is unclear to you. If you have access to the upstream build process, then separating the build of the MPI library would make a world of sense, as 99% of the Boost library is serial code that is independent of any MPI runtime and you don't need to rebuild it with every MPI compiler.
(In reply to comment #0) Like Petr, I had no idea that MPI package guidelines existed. > MPICH2 also still blatantly violates the guidelines by providing alternatives > support, thus making itself available by default, which explains why you have > been able to build without explicitly loading MPI support in the spec file with > %{_mpich2_load}. I now understand why the Boost.MPI build process took MPICH2 by default. > so you really should build also a package against Open MPI, as it is really the > traditional MPI runtime on Fedora and is a *lot* easier to setup on a shared > memory computer than MPICH2. I am glad to read that, as I also find OpenMPI easier to set-up and to run. And it also seems to have more "industrial strength" (to be more mature for use in production). However, I already tried to build Boost.MPI with OpenMPI, and the only way I could achieved that goal was to hard-code the install paths of OpenMPI in the CMake configuration of Boost... which is surely not the Fedora way. I asked upstream (Boost-CMake group) whether they was a better way (http://lists.boost.org/boost-cmake/2009/12/0861.php), but have not received any response yet. So, if you know how we could fix that, I would be very happy to hear about it!
(In reply to comment #3) > > so you really should build also a package against Open MPI, as it is really the > > traditional MPI runtime on Fedora and is a *lot* easier to setup on a shared > > memory computer than MPICH2. > > I am glad to read that, as I also find OpenMPI easier to set-up and to run. And > it also seems to have more "industrial strength" (to be more mature for use in > production). > > However, I already tried to build Boost.MPI with OpenMPI, and the only way I > could achieved that goal was to hard-code the install paths of OpenMPI in the > CMake configuration of Boost... which is surely not the Fedora way. The build process shouldn't make any assumptions about the compilers or paths used - MPI is a standardized library, just as the C standard library. You just need to get rid of everything that points to MPICH2 and replace the compiler commands with mpicc, mpic++, mpif90 and so on. These wrapper commands provide all the needed include paths, libraries etc.
There are two components that depend on MPI currently, the Boost.MPI library and Parallel Boost Graph Library. Necessity of special-handling Boost.MPI is obvious, but we will also need to fix Parallel BGL, which is now incorrectly swiped to boost-graph subpackage. What will be necessary is boost-graph-openmpi and boost-graph-mpich2 subpackages.
(In reply to comment #4) > You just need to get rid of everything that points to MPICH2 and replace the > compiler commands with mpicc, mpic++, mpif90 and so on. These wrapper commands > provide all the needed include paths, libraries etc. So, if I well understand the principle, Boost-CMake configuration should just refer to standardized MPI (e.g., mpicc, mpic++), while it is up to the specification file of the Boost package to "pre-load" either one of the MPI implementations (MPICH2, OpenMPI, LAM-MPI) before Boost actually builds (in the %build step). Also, I've read the bunch of new bugs which have been filed against MPICH2: https://admin.fedoraproject.org/pkgdb/packages/bugs/mpich2. It is very informative. In short, I believe I can contribute to the (new) Boost specification file so that it complies with the MPI packaging guidelines (http://fedoraproject.org/wiki/PackagingDrafts/MPI), but it will first only ship the boost-mpich2-* sub-packages, as I do not know, yet, how to build Boost.MPI with other MPI compilers (OpenMPI and LAM-MPI) appropriately. If you can help, do not hesitate. ---- Besides, Boost.MPI also builds a Python module, namely mpi.so, which I get rid of in the Boost specification file... because I do not know how to handle (see my post on the Boost-CMake mailing-list: http://lists.boost.org/boost-cmake/2009/11/0752.php, and the answer: http://lists.boost.org/boost-cmake/2009/11/0753.php ; no more answers were given). The issue is that that mpi.so Python module is not linked with enough explicit dependencies (e.g., on other Boost libraries). Hence, when Python executes the "import mpi" command, the dynamic loader can not find many required symbols. By explicitly adding (manually) a few more Boost libraries in the linking process, I got rid of most of those undefined symbols, but a few ones (about Boost serialization) were still resisting. An easy way to check that the Python module is correctly linked/built is with the "ldd -r mpi.so" command. But, as I am neither an MPI nor Python expert, I may have missed a few things. I guess that once the Python MPI module will have been solved, it will have to be placed in %{python_sitearch}/%{name}%{?_cc_name_suffix}/ ? So, again, any help will be welcome. If that issue is not solved in time (for the release of Fedora 13), the Python module will simply not be delivered.
(In reply to comment #6) > (In reply to comment #4) > > You just need to get rid of everything that points to MPICH2 and replace the > > compiler commands with mpicc, mpic++, mpif90 and so on. These wrapper commands > > provide all the needed include paths, libraries etc. > > So, if I well understand the principle, Boost-CMake configuration should just > refer to standardized MPI (e.g., mpicc, mpic++), while it is up to the > specification file of the Boost package to "pre-load" either one of the MPI > implementations (MPICH2, OpenMPI, LAM-MPI) before Boost actually builds (in the > %build step). Exactly. The only thing you should need to worry about is making the MPI compiler commands available in the build phase. PS. I hope LAM-MPI was just an example, as it's been obsolete for a long time (it doesn't even support version 2 of the MPI standard) and it has been finally removed from rawhide some time ago :) > I guess that once the Python MPI module will have been solved, it will have to > be placed in %{python_sitearch}/%{name}%{?_cc_name_suffix}/ ? Yes, otherwise it will clash with the library compiled against other MPI libraries. Note that here %{name} refers to the MPI compiler, i.e. openmpi or mpich2.
(In reply to comment #7) > PS. I hope LAM-MPI was just an example, as it's been obsolete for a long time > (it doesn't even support version 2 of the MPI standard) and it has been finally > removed from rawhide some time ago :) Yes, sure! Nevertheless, I would be unable to build Boost.MPI (and Boost.Graph) with it... > Yes, otherwise it will clash with the library compiled against other MPI > libraries. Note that here %{name} refers to the MPI compiler, i.e. openmpi or > mpich2. Yes, it is better to specify that. Thanks for your feedbacks. I'll try to work on it this week-end.
Created attachment 387426 [details] boost-1.41.0-3.1 First attempt to comply with the MPI packaging guidelines.
(In reply to comment #9) > Created an attachment (id=387426) [details] > boost-1.41.0-3.1 The specification is "just" a re-work taking into account (I hope) most of the MPI packaging guidelines, around a Boost-CMake framework currently able to build only the MPICH2-dependent part. Since the build with OpenMPI does not work properly right now, it is de-activated by default. Do not hesitate to alter that specification file. For instance, I am not sure to have well understood how to activate/de-activate specific MPI implementation build.
Bah, I _knew_ I should have moved this to assigned. I spent some time on the packaging already. What is it about OpenMPI that doesn't work?
Created attachment 387433 [details] Patch against boost-1.41.0-3.1
(In reply to comment #12) > Created an attachment (id=387433) [details] > Patch against boost-1.41.0-3.1 The stuff about building against other compilers only applies to MPI compiler packages themselves. Everything else we build with the default compilers. The MPI packages need to require the relevant MPI runtime packages, if for nothing else then for dir ownership. The MPI development files go to compiler specific packages. Which reminds me - they should both Requires: boost-devel. Different MPI compilers are incompatible. When you load the compiler environment with a macro (that just basically loads the compiler module, e.g. "$ module load openmpi-x86_64" that sets the relevant paths etc), you lose whatever you had in those variables before. So, just before you configure and build your Open MPI version, you run %_openmpi_load, and straight after %_openmpi_unload. With MPICH2 the same thing. The libraries are installed in %{_libdir}/openmpi/lib, and binaries in %{_libdir}/openmpi/bin. Because the libraries are not visible by default (for a good reason, mind you!), any ldconfig stuff is unnecessary. When you want to run MPI stuff you load the runtime module you want, which sets LD_LIBRARY_PATH, PYTHONPATH and so on.
Created attachment 387467 [details] Spec Successful build (it's scratch and will go away eventually): http://koji.fedoraproject.org/koji/taskinfo?taskID=1950956 The spec file still needs some more work on cleaning up all the cut'n'pastes. I also want to take the bcond_with/without from Denis's spec and integrate them. Also I need to go through the Jussi's patch and see if anything applies (I've peeked in and that includes at least the mpi-devel subpackages). Also I didn't really sanity-check the binaries to check soname dependencies etc. Well, at least now it builds with MPI where it's supposed to and without where it's not. I'll work on that some more tomorrow.
Looks quite good already. However, %{__rm} -f $RPM_BUILD_ROOT/$MPI_LIB/mpi.so should use MPI_PYTHON_SITEARCH instead of MPI_LIB. There's still some other stuff in the patch you should go through, e.g. ldconfig which is unnecessary.
I wanted to ask whether there is a way to refer to %{_libdir}/openmpi/lib symbolically. In the build/install phase the path is abstracted away nicely with $MPI_LIB, but in %files section that can't be used.
(In reply to comment #15) > Looks quite good already. However, > %{__rm} -f $RPM_BUILD_ROOT/$MPI_LIB/mpi.so > should use MPI_PYTHON_SITEARCH instead of MPI_LIB. That depends on whether Boost installs mpi.so to $MPI_LIB or $MPI_PYTHON_SEARCH. In thought it is the former, and since I get no installed-but-unpackaged errors, that actually seems to be the case. In any case that means that when that file gets fixed, we will have to install it manually to the python directory, instead of the MPI directory where it ends up now.
(In reply to comment #16) > I wanted to ask whether there is a way to refer to %{_libdir}/openmpi/lib > symbolically. In the build/install phase the path is abstracted away nicely > with $MPI_LIB, but in %files section that can't be used. No, not currently, since you can't refer to shell variables in the %files section. Making macros %{_mpich2_libdir}, %{_mpich2_bindir} and so on in the relevant MPI compiler packages would actually be a nice addition to the MPI guidelines. They IIRC already state that the _load and _unload commands must be present, so it would be an easy task to expand the rpmmacro file with the above commands.
(In reply to comment #17) > (In reply to comment #15) > > Looks quite good already. However, > > %{__rm} -f $RPM_BUILD_ROOT/$MPI_LIB/mpi.so > > should use MPI_PYTHON_SITEARCH instead of MPI_LIB. > > That depends on whether Boost installs mpi.so to $MPI_LIB or > $MPI_PYTHON_SEARCH. In thought it is the former, and since I get no > installed-but-unpackaged errors, that actually seems to be the case. Ok. I just have to say that the library has a *really* crappy name if it isn't installed in a boost-specific directory. libboost_mpi.so would make *a lot* more sense... Btw. I'd appreciate if you made the %files section more specific by replacing *.so with libboost_*.so and *.a by libboost_*.a.
(In reply to comment #14) > Created an attachment (id=387467) [details] It looks quite good to me as well. rpmlint finds a bunch of errors (and quite a few warnings), but nothing actually difficult. If you include Jussi's feedbacks (and some of my inputs), it should be perfect :)
Created attachment 387659 [details] Spec A couple of minor adjustments, today I only had time to work on this a little. Backend selection now done via bcond_with/out. MPI-devel subpackages are there with proper glob in their file list. Dropped ldconfig calls in MPI packages. Subpackage interdependencies are not there yet and all the ugly duplicity is still present. A build: http://koji.fedoraproject.org/koji/taskinfo?taskID=1952361 Denis, I don't plan to work on that over the weekend. Should you want to give it a go, feel free, there will be no collisions this time. Otherwise I'll wrap it up on Monday.
The packages boost-{openmpi,mpich2}-devel need to Requires: boost-devel. ** # MPI subpackages don't need the ldconfig magic. They are hidden by # default, in MPI backend-specific directory, and only show after the # relevant MPI rpm build macro is issued. is not completely correct, it should be # MPI subpackages don't need the ldconfig magic. They are hidden by # default, in MPI backend-specific directory, and only show to the user after the # relevant environment module has been loaded. ** Otherwise I couldn't find anything else with a quick glance, everything seems fine now.
Created attachment 387791 [details] Patch against Boost-1.41.0-4 1.1. The explicit dependencies on boost-{openmpi,mpich2}-devel sub-packages have been removed from the main package. 1.2. The {openmpi,mpich2}-devel sub-packages depend on the {openmpi,mpich2} packages. Hence 'Requires: boost-openmpi = %{version}-%{release}' and 'Requires: boost-mpich2 = %{version}-%{release}' have been added. It appears more logic that way, and rpmlint did report a warning about that (a non-devel package depending on a -devel sub-package). 2. The 'Requires: openmpi' and 'Requires: mpich2' have been commented out, as the packaging process detects that {OpenMPI,MPICH2}-based Boost libraries (e.g., libboost_mpi.so.5) need {OpenMPI,MPICH2} libraries (e.g., libmpi.so.0 and libmpi_cxx.so.0). However, I may have missed something (I do not understand why those explicit requirements had been added, and I guess you certainly had a good reason for that. Hadn't you?). 3. The MPI_COMPILER environment variable had to be altered when OpenMPI is loaded, because of the bug: https://bugzilla.redhat.com/show_bug.cgi?id=560224 A work-around is to add the following two lines each time the OpenMPI module is loaded: MPI_COMPILER=openmpi-%{_arch} export MPI_COMPILER Again, I may have missed something. Do not hesitate to explain "for a dummy" if the MPI_COMPILER environment variable was correctly set. 4. The comment "# MPI subpackages don't need the ldconfig magic [...]" has been moved before the postin/postun section because rpmlint was complaining that the lines were not empty after '%postun wave -p /sbin/ldconfig' (which is the last one of that section). I guess that that warning is not very important, but since moving the comment a few lines above solved the issue, it may be worth it.
Created attachment 387793 [details] boost-1.41.0-4.1 The specification file corresponds to Petr's one (boost-1.41.0-4), on which Jussi's feedback and my patch have been applied. I have attached it for convenience reason. Koji is on its way...
(In reply to comment #23) > 1.2. The {openmpi,mpich2}-devel sub-packages depend on the {openmpi,mpich2} > packages. Hence 'Requires: boost-openmpi = %{version}-%{release}' and > 'Requires: boost-mpich2 = %{version}-%{release}' have been added. > > It appears more logic that way, and rpmlint did report a warning about that (a > non-devel package depending on a -devel sub-package). Maybe I wasn't clear enough: boost-openmpi-devel and boost-mpich2-devel need to Requires: boost-devel = %{version}-%{release}, since the MPI devel packages probably need at least the headers that are in boost-devel. > 2. The 'Requires: openmpi' and 'Requires: mpich2' have been commented out, as > the packaging process detects that {OpenMPI,MPICH2}-based Boost libraries > (e.g., libboost_mpi.so.5) need {OpenMPI,MPICH2} libraries (e.g., libmpi.so.0 > and libmpi_cxx.so.0). > > However, I may have missed something (I do not understand why those explicit > requirements had been added, and I guess you certainly had a good reason for > that. Hadn't you?). The explicit dependency is a safeguard to protect from the wrong MPI runtime being picked up, as e.g. both Open MPI and MPICH2 provide libmpi. > 3. The MPI_COMPILER environment variable had to be altered when OpenMPI is > loaded, because of the bug: https://bugzilla.redhat.com/show_bug.cgi?id=560224 > A work-around is to add the following two lines each time the OpenMPI module is > loaded: > MPI_COMPILER=openmpi-%{_arch} > export MPI_COMPILER > > Again, I may have missed something. Do not hesitate to explain "for a dummy" if > the MPI_COMPILER environment variable was correctly set. Good catch. But this shouldn't really matter, as the $MPI_COMPILER variable is a dummy one, only used for notekeeping to differentiate the builds.
Created attachment 387839 [details] boost-1.41.0-4.1
Created attachment 387890 [details] boost-1.41.0-4.1
Created attachment 387891 [details] Patch against boost-1.41.0-4
Created attachment 387892 [details] boost-1.41.0-4.1
boost-mpich2-python should probably still Requires: boost-mpich2, same thing for boost-openmpi-python..? Or if the python packages don't depend on libboost_mpi then just Requires: mpich2 and Requires: openmpi on the MPI python packages.
(In reply to comment #25) > boost-openmpi-devel and boost-mpich2-devel need to > Requires: boost-devel = %{version}-%{release}, since the MPI devel packages > probably need at least the headers that are in boost-devel. It is now clearer :) I have added "Requires: boost-{openmpi,mpich2} = %{version}-%{release}" as well because rpmlint was reporting a warning. However, I would say that, since boost-{openmpi,mpich2}-devel requires boost-devel, since boost-devel requires boost and since boost requires boost-{openmpi,mpich2}, by transitivity (and Yum will find it correctly, I believe), it should not needed to specify explicitly that requirement (boost-{openmpi,mpich2}-devel requires boost-{openmpi,mpich2}). What should we do here? Keep that explicit direct requirement statement, in order to silent rpmlint, or remove it for more logic? Or did I miss something? > > 2. The 'Requires: openmpi' and 'Requires: mpich2' have been commented out... > > The explicit dependency is a safeguard to protect from the wrong MPI runtime > being picked up, as e.g. both Open MPI and MPICH2 provide libmpi. You are right. For instance, I do not know which one of the packages the RPM builder takes when it detects the requirement for, say, libmpi.so.0. However, we may have an undesirable dependency here. Say that, when building the boost-mpich2 sub-package (and detecting the need for the libmpi.so.0 library), the RPM build process picks up the OpenMPI package for providing the libmpi.so.0 package (in addition to the explicit requirement for MPICH2). It will mean that when a developer will install boost-mpich2, he/she will get OpenMPI (in addition to MPICH2). Note that, if I am right, this should not be too big a problem, though, now that both OpenMPI and MPICH2 will have given up their use of the alternative mechanism. -------------------- Now, purists will say that rpmlint reports numerous errors (and a few warnings). Shouldn't we report those as enhancement suggestions for rpmlint (as those are not really errors)? I am not sure it is worth it, as there should not be so many packages in Fedora with so complex a structure (an "umbrella" package with many sub-packages, some of them being further -devel sub-packages).
(In reply to comment #30) > boost-mpich2-python should probably still Requires: boost-mpich2, same thing > for boost-openmpi-python..? Or if the python packages don't depend on > libboost_mpi then just Requires: mpich2 and Requires: openmpi on the MPI python > packages. You are right: $ ldd -r <build>/boost-1.41.0.cmake0/openmpi-x86_64/lib/libboost_mpi_python.so.5 libmpi_cxx.so.0 => /usr/lib64/openmpi/lib/libmpi_cxx.so.0 libmpi.so.0 => /usr/lib64/openmpi/lib/libmpi.so.0 libopen-rte.so.0 => /usr/lib64/openmpi/lib/libopen-rte.so.0 libopen-pal.so.0 => /usr/lib64/openmpi/lib/libopen-pal.so.0 [...] libboost_mpi.so.5 => /usr/lib64/libboost_mpi.so.5 libmpichcxx.so.1.2 => /usr/lib64/mpich2/lib/libmpichcxx.so.1.2 libmpich.so.1.2 => /usr/lib64/mpich2/lib/libmpich.so.1.2 However, we notice that that library depends on both OpenMPI and MPICH2 (hmmm, that one may not be easy to solve).
(In reply to comment #31) > What should we do here? Keep that explicit direct requirement statement, in > order to silent rpmlint, or remove it for more logic? Or did I miss something? Keep the explicit statements, of course. It doesn't hurt having them. > However, we may have an undesirable dependency here. Say that, when building > the boost-mpich2 sub-package (and detecting the need for the libmpi.so.0 > library), the RPM build process picks up the OpenMPI package for providing the > libmpi.so.0 package (in addition to the explicit requirement for MPICH2). It > will mean that when a developer will install boost-mpich2, he/she will get > OpenMPI (in addition to MPICH2). Logically thinking, the explicit statement should force the correct runtime is picked up. If the resolver does things smartly, it should see that the explicit requirement already takes care of the libmpi requirement. > Note that, if I am right, this should not be too big a problem, though, now > that both OpenMPI and MPICH2 will have given up their use of the alternative > mechanism. Open MPI has given up using the alternatives system a *long* time ago. > Now, purists will say that rpmlint reports numerous errors (and a few > warnings). Shouldn't we report those as enhancement suggestions for rpmlint (as > those are not really errors)? I am not sure it is worth it, as there should not > be so many packages in Fedora with so complex a structure (an "umbrella" > package with many sub-packages, some of them being further -devel > sub-packages). You don't have to care about all rpmlint warnings, since rpmlint is a cross-distro utility and it doesn't care about Fedora specifics.
(In reply to comment #32) > You are right: > $ ldd -r > <build>/boost-1.41.0.cmake0/openmpi-x86_64/lib/libboost_mpi_python.so.5 > libmpi_cxx.so.0 => /usr/lib64/openmpi/lib/libmpi_cxx.so.0 > libmpi.so.0 => /usr/lib64/openmpi/lib/libmpi.so.0 > libopen-rte.so.0 => /usr/lib64/openmpi/lib/libopen-rte.so.0 > libopen-pal.so.0 => /usr/lib64/openmpi/lib/libopen-pal.so.0 > [...] > libboost_mpi.so.5 => /usr/lib64/libboost_mpi.so.5 ^^^^^^^^^^^^^^^^^^^ This here looks a bit odd. Where did you run the command? Do you incidentally have an old package installed?
Created attachment 387907 [details] Patch against Boost-1.41.0-4
Created attachment 387908 [details] boost-1.41.0-4.1
(In reply to comment #34) > > libboost_mpi.so.5 => /usr/lib64/libboost_mpi.so.5 > ^^^^^^^^^^^^^^^^^^^ > This here looks a bit odd. Where did you run the command? Do you incidentally > have an old package installed? Yes, you are right, I've not (yet) re-installed the newest version of Boost. My installed version is 1.41.0-1.1.fc12 (well before MPI-dependent libraries have been buried deeper in the hierarchy). But do you think it is normal that libboost_mpi_python.so depends on both OpenMPI and MPICH2 libraries?
(In reply to comment #37) > But do you think it is normal that libboost_mpi_python.so depends on both > OpenMPI and MPICH2 libraries? My guess is that they don't, really. You just probably have some odd mix of packages on your system, or a really odd mix of environment variables. Was that a local build you ran? Does the same thing come up with a mock build?
(In reply to comment #38) > Was that a local build you ran? Does the same thing come up with a mock build? Yes, I ran a local build, but should check with mock today. In the meantime, Koji (successful) results are here: http://koji.fedoraproject.org/koji/taskinfo?taskID=1955425
(In reply to comment #39) > (In reply to comment #38) > > Was that a local build you ran? Does the same thing come up with a mock build? > > Yes, I ran a local build, but should check with mock today. In the meantime, > Koji (successful) results are here: > http://koji.fedoraproject.org/koji/taskinfo?taskID=1955425 Koji uses mock internally, so the end result is the same. Do you see the same thing with only the packages created in mock/koji installed?
Latest build log looks fine to me. http://koji.fedoraproject.org/koji/getfile?taskID=1955427&name=build.log Thanks for working on this Denis
(In reply to comment #37) > (In reply to comment #34) > > > libboost_mpi.so.5 => /usr/lib64/libboost_mpi.so.5 > > ^^^^^^^^^^^^^^^^^^^ Following are the results with the new version of Boost (1.41.0-4.1): $ ldd -r /usr/lib64/openmpi/lib/libboost_mpi_python.so.5 [...] libmpi_cxx.so.0 => /usr/lib64/openmpi/lib/libmpi_cxx.so.0 libmpi.so.0 => /usr/lib64/openmpi/lib/libmpi.so.0 libopen-rte.so.0 => /usr/lib64/openmpi/lib/libopen-rte.so.0 libopen-pal.so.0 => /usr/lib64/openmpi/lib/libopen-pal.so.0 libboost_mpi.so.5 => /usr/lib64/openmpi/lib/libboost_mpi.so.5 libpython2.6.so.1.0 => /usr/lib64/libpython2.6.so.1.0 libboost_python.so.5 => /usr/lib64/libboost_python.so.5 libboost_serialization.so.5 => /usr/lib64/libboost_serialization.so.5 [...] For the sake of completeness, following are the same results for the corresponding MPICH2 libraries: $ ldd -r /usr/lib64/mpich2/lib/libboost_mpi_python.so.5 [...] libmpichcxx.so.1.2 => /usr/lib64/mpich2/lib/libmpichcxx.so.1.2 libmpich.so.1.2 => /usr/lib64/mpich2/lib/libmpich.so.1.2 libboost_mpi.so.5 => /usr/lib64/mpich2/lib/libboost_mpi.so.5 libpython2.6.so.1.0 => /usr/lib64/libpython2.6.so.1.0 libboost_python.so.5 => /usr/lib64/libboost_python.so.5 libboost_serialization.so.5 => /usr/lib64/libboost_serialization.so.5 [...] So, it appears right now.
boost-graph-$MPI still needs to depend explicitly on boost-$MPI, otherwise it will depend only on libboost_mpi.so.1.41.0 and that dependency is satisfied by any MPI flavor. I also changed the umbrella package to not drag in the MPI stuff at all. MPI seems like a "speacial" area that the administrator will want to handle separately, and having all supported MPI backends around just because some package accidentally depends on "boost" is a problem I think. Similarly I've added dependencies on boost-$MPI* packages to boost-$MPI-devel. That's necessary because we deliver DSO symlinks in -devel, and those would end up dangling. So the $MPI-devel subpackage now works as an MPI flavor umbrella package for development purposes. The build is here: http://koji.fedoraproject.org/koji/taskinfo?taskID=1959110 Looking through the dependencies with rpmreaper in mock, and it all looks good to me now. rpmlint errors and warnings that it reports are all defensible as special cases. I'm inclined to call it done. It's sitting in CVS, so unless anyone has further comments, I'll tag and build it for rawhide tomorrow.
(In reply to comment #43) > I also changed the umbrella package to not drag in the MPI stuff at all. MPI > seems like a "special" area that the administrator will want to handle > separately, and having all supported MPI backends around just because some > package accidentally depends on "boost" is a problem I think. Yes, you are perfectly right. > So the $MPI-devel subpackage now works as an MPI flavor umbrella package for > development purposes. That's clean and logic. > I'm inclined to call it done. It's sitting in CVS, so unless anyone has > further comments, I'll tag and build it for rawhide tomorrow. That sounds perfect to me.
And here's the rawhide build: http://koji.fedoraproject.org/koji/taskinfo?taskID=1960702 There are still nits in the spec that could be improved, namely the notorious code duplication, but that can wait for another time. Thanks for collaboration!