This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 529563 - boost: add the Boost.MPI library within the boost package
boost: add the Boost.MPI library within the boost package
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: boost (Show other bugs)
rawhide
All Linux
medium Severity low
: ---
: ---
Assigned To: Benjamin Kosnik
Fedora Extras Quality Assurance
http://www.boost.org/doc/libs/1_39_0/...
: FutureFeature
Depends On: 496188 559009
Blocks: 520087 533922
  Show dependency treegraph
 
Reported: 2009-10-18 13:49 EDT by Denis Arnaud
Modified: 2013-08-09 01:49 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
: 607615 (view as bug list)
Environment:
Last Closed: 2010-02-03 13:22:03 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
boost-1.41.0-cmake0 spec (25.05 KB, application/x-troff-man)
2009-12-17 02:57 EST, Benjamin Kosnik
no flags Details
forward port to 1.41 (394 bytes, application/octet-stream)
2009-12-17 02:57 EST, Benjamin Kosnik
no flags Details
RPM Spec file for the boost-cmake-1.41.1 version (25.63 KB, text/plain)
2009-12-17 12:42 EST, Denis Arnaud
no flags Details
RPM Spec file for the boost-cmake-1.41.0 version (25.67 KB, text/plain)
2009-12-17 17:42 EST, Denis Arnaud
no flags Details
boost spec file, edit 8 (25.96 KB, text/plain)
2010-01-13 02:17 EST, Benjamin Kosnik
no flags Details
Spec file adjustments. (969 bytes, patch)
2010-01-13 14:07 EST, Petr Machata
no flags Details | Diff
Spec file for Boost 1.41.0-1.1 (25.48 KB, application/octet-stream)
2010-01-14 10:49 EST, Denis Arnaud
no flags Details
boost-1.41.0-1.1 for Boost.MPI Python support kept separate (25.82 KB, application/octet-stream)
2010-01-14 11:41 EST, Denis Arnaud
no flags Details
boost-1.41.0-2.1 (25.99 KB, application/octet-stream)
2010-01-15 18:42 EST, Denis Arnaud
no flags Details
Spec file for Boost 1.41.0-2.2 (26.93 KB, application/octet-stream)
2010-01-18 13:32 EST, Denis Arnaud
no flags Details
Patch used by the spec file for Boost-1.41.0-2.2 (515 bytes, application/octet-stream)
2010-01-18 13:33 EST, Denis Arnaud
no flags Details

  None (edit)
Description Denis Arnaud 2009-10-18 13:49:10 EDT
Description of problem (not a bug, but an enhancement request):

Boost provides the Boost.MPI library (http://www.boost.org/doc/libs/1_39_0/doc/html/mpi.html), with a dependency on anyone of the existing MPI implementations (e.g., OpenMPI, MPICH2, both being packaged for Fedora). I guess that it is why that library is not included in the Fedora package of boost/boost-devel.

So, now that the boost package has been designed so as allow depending on specific boost sub-packages (date-time, serialization, system, etc.), it would nice to get a boost-mpi sub-package (and to include the Boost.MPI within the boost-devel package).

From what I see, it should not be too difficult, just for the Boost.MPI inclusion in the boost.spec. But it could imply many side effects, and that it is where I would need your help and experience in tackling such issues (if any).
Comment 1 Benjamin Kosnik 2009-10-20 12:17:53 EDT
I am in favour of shipping boost.MPI. It looks like you've already done some work on this, but I am away this week and will not be able to review it until I get back. 

Just out of curiosity, which MPI implementation will boost.MPI depend on? Which is preferred?
Comment 2 Denis Arnaud 2009-10-20 13:22:04 EDT
Thanks for your answer. Boost.MPI seems to depend on MPICH2: without any specific configuration, bjam generates compilation directive with /usr/include/mpich2 and /usr/lib/mpich2. But it can be changed with a proper bjam configuration, maybe (as, on a pure code level, Boost relies only the standard MPI API)?

As I understand, OpenMPI seems to be more oriented toward "production-grade" products, and MPICH2 toward research projects. But I may have missed some point.
Comment 3 Denis Arnaud 2009-10-20 14:01:57 EDT
Have some of you looked at an alternative to bjam?
I've in mind GNU Boost: http://boost-extras.sourceforge.net/ (its README file reminds me a lot of difficulties I've already had with bjam)
Comment 4 Benjamin Kosnik 2009-10-20 14:49:21 EDT
Re# 3

Well yes, personally I am in favor of moving to cmake instead of bjam to build boost for fedora. I always recommend against using bjam outside of boost itself.

The GNU boost project looks a bit out-of-date, since 1.35.0 there was the addition of a pseudo-configure script to boost proper that mostly does the job (although is not a full conversion to autotools). Although changes to the boost build process for each release seems de rigueur, we are able to make this approach work.

There is some effort at using a sane build tool (cmake) by a faction of the boost developers. Whenever possible I try to support these efforts, although I have not investigated using this for the 1.41 package. See:

http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
Comment 5 Denis Arnaud 2009-10-20 17:18:45 EDT
Thanks for the pointers. I also believe it makes sense to migrate to CMake (e.g., for the use of native compilers), as it is officially supported by Fedora (https://fedoraproject.org/wiki/Packaging/cmake). However, I hardly know that building tool; so, I won't be of much help there. But, as the Boost-CMake mailing list suggests, there is much activity over there.

I've just tried (with CMake), within the clean upstream version 1.39.0 of Boost:
cmake -DCMAKE_IS_EXPERIMENTAL=YES_I_KNOW -G "Unix Makefiles"
make -i
and it builds all combinations of libraries (static and dynamic, debug and release, multi-threaded), but the accumulator library:
===============
[ 47%] Building CXX object libs/accumulators/example/CMakeFiles/accumulators-accumulators_example.dir/main.cpp.o
/home/build/dev/fedora/reviewsvn/boost_529563/boost_1_39_0/boost/accumulators/statistics_fwd.hpp: In function ‘void example1()’:
/home/build/dev/fedora/reviewsvn/boost_529563/boost_1_39_0/boost/accumulators/statistics_fwd.hpp:87: error: ‘template<int N> struct boost::accumulators::tag::moment’ is not a function,
/home/build/dev/fedora/reviewsvn/boost_529563/boost_1_39_0/boost/accumulators/statistics/moment.hpp:104: error:   conflict with ‘template<int T2, class Arg1, class A0, class A1, class A2, class A3, class A4, class A5, class A6, class A7, class A8, class A9, class A10, class A11, class A12, class A13, class A14> typename boost::accumulators::detail::extractor_result<Arg1, boost::accumulators::tag::moment<T2> >::type boost::accumulators::extract::moment(const Arg1&, const A0&, const A1&, const A2&, const A3&, const A4&, const A5&, const A6&, const A7&, const A8&, const A9&, const A10&, const A11&, const A12&, const A13&, const A14&)’
/home/build/dev/fedora/reviewsvn/boost_529563/boost_1_39_0/libs/accumulators/example/main.cpp:63: error:   in call to ‘moment’
make[2]: *** [libs/accumulators/example/CMakeFiles/accumulators-accumulators_example.dir/main.cpp.o] Error 1
make[1]: *** [libs/accumulators/example/CMakeFiles/accumulators-accumulators_example.dir/all] Error 2
make: *** [all] Error 2
===============

the Boost.MPI library builds cleanly (and links with the MPICH2 library, even when OpenMPI-devel has been installed. Again, that may be due to the configuration of CMake).
Comment 6 Denis Arnaud 2009-10-24 18:17:49 EDT
After a few tries, I eventually achieved to adapt the specification file to (Boost-)CMake build, and of course to Boost.MPI. I took that opportunity to add an "accumulators" package.
Note that, as CMake builds example binaries, and as there is a compilation error with the accumulators example binary, I also had to fix it (https://svn.boost.org/trac/boost/ticket/3543).

==================
RPM Spec: http://denisarnaud.fedorapeople.org/boost/1.39.0/10/boost.spec
SRPM: http://denisarnaud.fedorapeople.org/boost/1.39.0/10/boost-1.39.0-10.fc11.src.rpm
Additional patches: http://denisarnaud.fedorapeople.org/boost/1.39.0/10/
==================

Thanks to CMake, we should even be able to remove the part on ad-hoc installation of libraries, if we find how to patch Boost-CMake configuration file so that /usr/lib64 be used on 64bit platforms (instead of /usr/lib).

I have successfully tested that specification both on the F-11 and devel branches.

Your feedbacks are welcome.
Comment 7 Denis Arnaud 2009-10-24 19:26:31 EDT
Builds on Koji:
* Fedora rawhide: http://koji.fedoraproject.org/koji/taskinfo?taskID=1766482
* Fedora 11-like: http://koji.fedoraproject.org/koji/taskinfo?taskID=1766480
Comment 8 Denis Arnaud 2009-10-25 18:03:36 EDT
Note that there are some (seemingly-easy-to-fix) errors (rightly) reported by rpmlint (e.g., about the absence of post-install scriptlets), but I wait for your feedback before going on fixing them.
Comment 9 Denis Arnaud 2009-10-26 14:14:26 EDT
By the way, since we are at re-delivering Boost (at least) for Fedora rawhide, we may take that opportunity to deliver the latest version, currently 1.40.0 (as of time writing, though it should become 1.41.0 very soon): http://sodium.resophonic.com/boost-cmake/1.40.0.cmake2/

I work on updating the RPM specification file for that version. There were two compilation errors, which can be fixed with a simple patch: https://svn.boost.org/trac/boost/ticket/3565
Comment 10 Denis Arnaud 2009-10-29 06:53:32 EDT
I now get a RPM specification file generating Boost libraries with CMake (it simplifies a lot the building process!), and for the version 1.40.0 of Boost.
===================
RPM specification file: http://denis.arnaud.free.fr/fedora/boost/1.40.0.cmake2/boost.spec
Source RPM: http://denis.arnaud.free.fr/fedora/boost/1.40.0.cmake2/boost-1.40.0.cmake2-10.fc11.src.rpm
===================

rpmlint only reports warnings on missing documentation from sub-packages.

Note that the Boost-CMake community is very active, and is very willing to help Linux distribution packagers, including us. See for instance the following two threads on the boost-cmake mailing list: http://lists.boost.org/boost-cmake/2009/10/0686.php and http://lists.boost.org/boost-cmake/2009/10/0660.php .

Any feedback is welcome.
Comment 11 Denis Arnaud 2009-11-02 14:34:57 EST
Thanks to Troy d. Straszheim (http://lists.boost.org/boost-cmake/2009/10/0740.php), the latest Boost-CMake add-ons allow fully generating all the Boost libraries (and sub-packages) for the version 1.40.0 (at least) of Boost.

===================
RPM specification file: http://denisarnaud.fedorapeople.org/boost/1.40.0/10/boost.spec
Source RPM: http://denisarnaud.fedorapeople.org/boost/1.40.0/10/boost-1.40.0-10.fc11.src.rpm
===================

---------------------------------------

I have tested a build on Fedora 11, for both the 32 and 64bit variations. rpmlint reports only warnings:
-------
a) For missing docs within each of the sub-packages (but since there is a dedicated doc sub-package, it may be fine).
b) Because the $RPM_BUILD_ROOT is being used during the %build phase (but, as it used by %cmake, I do not see how we could do otherwise).
c) The boost-graph library sub-package calls exit() (or _exit()). We should certainly address that upstream, but I do not think it to be a show-stopper.

---------------------------------------

I now need your feedbacks:
-------
1. What do you think of releasing the CMake-aware version 1.40.0 of Boost?
2. I suppose we should then trigger a full rebuild of the packages depending on the corresponding Boost libraries. How should we organise that (if you agree to go on with that CMake-aware version, of course)?

---------------------------------------
Comment 12 Denis Arnaud 2009-11-02 15:48:02 EST
(Successful) Build on Koji (x86_64 Fedora 11): http://koji.fedoraproject.org/koji/taskinfo?taskID=1783664
Comment 13 Denis Arnaud 2009-11-04 15:35:26 EST
The latest commits on the 1.40.0 branch of Boost-CMake (http://gitorious.org/boost/cmake/commits/1.40.0) now allow to build all the Boost RPMs very cleanly. Only a warning is remaining (the boost-graph library sub-package calling exit()).

===================
RPM specification file:
http://denisarnaud.fedorapeople.org/boost/1.40.0/10/boost.spec
Source RPM:
http://denisarnaud.fedorapeople.org/boost/1.40.0/10/boost-1.40.0-10.fc11.src.rpm
===================

See above (https://bugzilla.redhat.com/show_bug.cgi?id=529563#c11) for the need of feedback.
Comment 14 Benjamin Kosnik 2009-11-04 21:42:53 EST
Well, I think this looks very promising. I would suggest targeting the 1.4 release, and rebasing to that source tree.

So:

Version: 1.40.0
Release: 10%{?dist}

Should be

Version: 1.41.0
Release: 0.1%{?dist}

Then this would be targeted at F13, when the trunk from F12 clears. Can you try building this in koji?

What are SONAMEs on the generated libraries and how does this compare to the current 1.39 SONAMES?

best,
benjamin
Comment 15 Benjamin Kosnik 2009-11-04 21:46:11 EST
I mean target the upcoming 1.41 release.

To answer directly:

1. I think that the 1.41 rebase (scheduled for F13) should use cmake if possible and not too much work

2. boost rebases usually update SONAME and require rebuilding of all dependencies. If this is the case, then it's announced and ask package owners to help out, build some of them as time allows. The last couple of times have been pretty smooth.
Comment 16 Denis Arnaud 2009-11-05 04:10:22 EST
Now that the version 1.40.0 of Boost builds cleanly with CMake, I'll target to switch onto the version 1.41.0, as you suggest. And, yes, it seems wise to target F13, after the release of F12. So, we may target to begin the migration early next year, I guess.

By the way, the first Boost-CMake beta of the first Boost beta has just been released: http://lists.boost.org/boost-cmake/2009/11/0751.php .

As for the sonames, it is now like Debian packagers do, i.e., the sonames are following Boost versionning (there was a good discussion last year in the Debian list here: http://lists.alioth.debian.org/pipermail/pkg-boost-devel/2008-November/001611.html). For instance, the soname of the version 1.41.0 of libboost_date_time-mt.so will be libboost_date_time-mt.so.1.41.0
As I understand, that is a change compared to the situation of current Fedora packaging process (where the last soname version was 5, for instance).

Upstream Boost now releases four times a year, and they have no mean to ensure ABI compatibility for each of the specific libraries. Hence, the version (e.g., 1.41.0) is global for all the libraries, and the binaries depending on those libraries have to be at least re-linked when the Boost global version changes. 

That is why, I guess, we do not upgrade Boost during the life-cycle of any Fedora release (for instance, Boost versions remain in versions 1.35.0, 1.37.0 and 1.39.0 respectively during the lifetimes of F10, F11 and F12). I guess that it is the same for RedHat/CentOS releases (for instance, Boost 1.34.0 on RedHat/CentOS 5).

Hence, it seems reasonable (at least to me) to synchronise the sonames with the global version of Boost. It moreover simplifies the build process. If you do not agree with that, I'll have to find how we can tailor the CMake-based building process. See the extensive debate about that subject on the Boost-CMake mailing list: http://lists.boost.org/boost-cmake/2009/10/0686.php

Does it sound reasonable?
Comment 17 Petr Machata 2009-11-10 06:18:03 EST
I personally don't know why boost in Fedora uses soname versioning rules it uses.  I don't think there would be a problem if you just used the specific boost version as a soname suffix, so if that's what CMake produces, let's go with that.
Comment 18 Benjamin Kosnik 2009-12-16 03:59:10 EST
Hey guys. What's up with this?
Comment 19 Denis Arnaud 2009-12-16 13:04:26 EST
I've had success in building RPMs for Boost v1.40.0 with CMake (I'll post the spec and source RPM files later tonight, but they are just slightly different from those referenced above: I've just added a soname-compatibility mode for Fedora <= 12), installed and used them for a while on our farm of Fedora 12 servers, desktops and laptops in my company (as well as on Fedora rawhide at home), without any issue.

So, I'd suggest to begin with that version (Boost v1.40.0 with CMake), on Fedora rawhide and 13 (when created). Indeed, we could even push it to Fedora 12, as the soname stay the same (on that version of Fedora), and we'll therefore avoid to have to rebuild all the dependencies.

Then, when everything will be validated, we can upgrade to version 1.41.0 of Boost.

What do you think?
Comment 20 Denis Arnaud 2009-12-16 16:02:32 EST
===================
RPM specification file:
http://denisarnaud.fedorapeople.org/boost/1.40.0/12/boost.spec
Source RPM:
http://denisarnaud.fedorapeople.org/boost/1.40.0/12/boost-1.40.0-1.fc12.src.rpm
===================
Comment 21 Benjamin Kosnik 2009-12-17 02:56:21 EST
Dennis, hey. 

The version must be based on the 1.41.0: the whole point of this exercise is to break ABI only on set intervals, and the next interval is 1.41.0. Cmake and MPI are secondary although worthwhile goals.

Thus, I've been using the cmake 1.41.0 sources.

I've uploaded my WIP boost.spec based on 1.41.0-cmake0. Still, the problem with lib/lib64 persists....

[snip]

+ /bin/mkdir -p /home/bkoz/rpmbuild/BUILDROOT/boost-1.41.0-0.4.fc12.x86_64/usr/share/doc/boost-date-time-1.41.0
+ cp -pr LICENSE_1_0.txt /home/bkoz/rpmbuild/BUILDROOT/boost-1.41.0-0.4.fc12.x86_64/usr/share/doc/boost-date-time-1.41.0
+ exit 0


RPM build errors:
    File not found by glob: /home/bkoz/rpmbuild/BUILDROOT/boost-1.41.0-0.4.fc12.x86_64/usr/lib64/libboost_date_time*.so.1.41.0


I presume this is related to:
# Boost-CMake needs a variable to be defined for the lib directory on
# 64bit platforms (http://gitorious.org/boost/cmake/blobs/raw/1.40.0/tools/build/CMake/docs/build/html/build_configuration.html#boost-install-lib-subdir-name)
%if "%{?_lib}" == "lib64"
  %define _cmake_lib_suffix -DBOOST_INSTALL_LIB_SUBDIR_NAME=lib64
%endif

however, the "subdir-name" bits are missing from this documentation page. (And also for 1.41.0). Can you provide more info about this please?
Comment 22 Benjamin Kosnik 2009-12-17 02:57:22 EST
Created attachment 378926 [details]
boost-1.41.0-cmake0 spec
Comment 23 Benjamin Kosnik 2009-12-17 02:57:56 EST
Created attachment 378928 [details]
forward port to 1.41
Comment 24 Denis Arnaud 2009-12-17 12:42:45 EST
Created attachment 379061 [details]
RPM Spec file for the boost-cmake-1.41.1 version

Switching the source tar-ball to the one got from the 1.41.0-cmake branch head (http://gitorious.org/boost/cmake), I had to just slightly alter your specification file.

That new RPM specification file seems not too bad. The main issue I see is that the Boost libraries are delivered into the %{_libdir}/%{name}-%{version} sub-directory, instead of into %{_libdir}. But that may not be an issue (as it allows to have several versions of Boost in parallel).
Comment 25 Denis Arnaud 2009-12-17 17:42:39 EST
Created attachment 379113 [details]
RPM Spec file for the boost-cmake-1.41.0 version
Comment 26 Denis Arnaud 2009-12-17 18:09:46 EST
===================
RPM specification file:
http://denisarnaud.fedorapeople.org/boost/1.41.0/12/boost.spec
Source RPM:
http://denisarnaud.fedorapeople.org/boost/1.41.0/12/boost-1.41.0-0.6.fc12.src.rpm
===================  

As mentioned in #24, there is still the issue of the Boost libraries being delivered into the %{_libdir}/%{name}-%{version} sub-directory, instead of into %{_libdir}. Hence, it is not related to any lib64 issue (as you seemed to believe in #21).

As I understand from http://lists.boost.org/boost-cmake/2009/10/0733.php , setting INSTALL_VERSIONED to OFF should solve that problem, i.e., replacing:
%cmake -DENABLE_SINGLE_THREADED=YES -DCMAKE_BUILD_TYPE=RelWithDebInfo -DCMAKE_INSTALL_PREFIX=%{_prefix} ..
by:
%cmake -DENABLE_SINGLE_THREADED=YES -DINSTALL_VERSIONED=OFF -DCMAKE_BUILD_TYPE=RelWithDebInfo -DCMAKE_INSTALL_PREFIX=%{_prefix} ..

That option seems to be turned to ON by default, as seen in lines ##162-164 of the CMakeLists.txt configuration file:
if(UNIX)
  option(INSTALL_VERSIONED "Install to versioned directories" ON)
endif()

So, I'll try to test it tomorrow.
Comment 27 Denis Arnaud 2009-12-19 14:56:12 EST
===================
RPM specification file:
http://denisarnaud.fedorapeople.org/boost/1.41.0/12/boost.spec
Source RPM:
http://denisarnaud.fedorapeople.org/boost/1.41.0/12/boost-1.41.0-0.7.fc12.src.rpm
===================  

The Boost libraries are now delivered into the %{_libdir} directory, no longer in a versioned one. So, all seems fine by now.

Waiting for your feedback.
Comment 28 Denis Arnaud 2010-01-07 05:12:02 EST
Should we create a Feature/Enhancement (https://fedoraproject.org/wiki/Features/Policy) for that Boost upgrade for Fedora 13?
Comment 29 Benjamin Kosnik 2010-01-13 02:17:47 EST
Created attachment 383425 [details]
boost spec file, edit 8


Fixes test, removes debug, ups release.
Comment 30 Benjamin Kosnik 2010-01-13 02:20:34 EST
Yes, you can create a Feature Enhancement for MPI and the uplift to 1.41.0.

I've attached another edit of the spec file. This looks good, thanks for working on it. 

The change in SONAME name strategy is ok with me. 

Testing is still problematic but that is not a deal breaker.
Comment 31 Petr Machata 2010-01-13 14:07:36 EST
Created attachment 383540 [details]
Spec file adjustments.

- Is there a reason not to do this?
  -%if "%{?_lib}" == "lib64"
  -  %define _cmake_lib_suffix -DBOOST_INSTALL_LIB_SUBDIR_NAME=lib64
  -%endif
  +%define _cmake_lib_suffix -DBOOST_INSTALL_LIB_SUBDIR_NAME=%{?_lib}

- I dropped the soname patch, now that we've agreed about the soname naming convention.

- The package "accumulators" that was introduced in this package is empty.  Do accumulators have a runtime component, or is that a fluke in setup of our boost?  Or perhaps I'm missing some package that should be in BuildRequired.

- Similarly boost math, its contents disappeared.  I'll look into both more closely tomorrow.

- I think we can drop the license at the core "boost" package.  Each subpackage carries its own license, which is as it should be (placing it to core package might seem to make the most sense, but then you could install one of the "leaves" and end up license-less).
Comment 32 Denis Arnaud 2010-01-13 15:53:34 EST
(In reply to comment #31)
> - Is there a reason not to do this?
>   -%if "%{?_lib}" == "lib64"
>   -  %define _cmake_lib_suffix -DBOOST_INSTALL_LIB_SUBDIR_NAME=lib64
>   -%endif
>   +%define _cmake_lib_suffix -DBOOST_INSTALL_LIB_SUBDIR_NAME=%{?_lib}

From what I understand, the variable should be defined only on 64bit platforms, not on 32bit ones. What you suggest may work, though. But we may not rely on it working?

> - I dropped the soname patch, now that we've agreed about the soname naming
> convention.

That patch is convenient for testing on Fedora 11 & 12 (for instance, I use the Boost libraries delivered that way in order to work on other projects using Boost.MPI). However, since in Benjamin's version, that patch is not used, it should be either removed (like you did) or commented (which I prefer, for now, just for convenience reason).

> - The package "accumulators" that was introduced in this package is empty.  Do
> accumulators have a runtime component, or is that a fluke in setup of our
> boost?  Or perhaps I'm missing some package that should be in BuildRequired.
> 
> - Similarly boost math, its contents disappeared.  I'll look into both more
> closely tomorrow.

You are right, Boost.Math and Boost.Accumulators are header-only components. By the way, to get the exhaustive list of (non-header-only) Boost libraries, we can check: http://www.boost.org/doc/libs/1_41_0/more/getting_started/unix-variants.html#header-only-libraries

It thus means that we should not package separately the header-only components. From what I understand, that means that we should remove the boost-accumulators and boost-math sub-packages (all the other sub-packages have got actual libraries).
 
> - I think we can drop the license at the core "boost" package.  Each sub-package
> carries its own license, which is as it should be (placing it to core package
> might seem to make the most sense, but then you could install one of the
> "leaves" and end up license-less).    

By the way, if we remove the license file from the "boost" package, that latter will become empty (and rpmlint reports that as an error). Since the "boost" package is an umbrella, should we keep it empty (and handle the rpmlint error as an exception), or should we leave there some documentation file (for instance, a README explaining Boost RPM packaging in Fedora)?

--------------

I've begun to draft a Feature Request for Fedora 13: https://fedoraproject.org/wiki/Features/F13Boost141#Detailed_Description
Do not hesitate to contribute.
Comment 33 Benjamin Kosnik 2010-01-14 00:26:25 EST
> > - I dropped the soname patch, now that we've agreed about the
> > soname naming convention.
> 
> That patch is convenient for testing on Fedora 11 & 12 (for instance,
> I use the Boost libraries delivered that way in order to work on
> other projects using Boost.MPI). However, since in Benjamin's
> version, that patch is not used, it should be either removed (like
> you did) or commented (which I prefer, for now, just for convenience
> reason).

I also prefer to include the actual patch in the SRPM, but not activate
it. That was the plan with attaching the patch but not %patching it. 

It will help for people re-using this RPM, and help with the transition
to the new build system to have a bridge to the older equivalent.

Please keep this patch disabled but part of the SRPM so we don't have
to hunt around the internet to find it.

:)

> > - The package "accumulators" that was introduced in this package is
> > empty.  Do accumulators have a runtime component, or is that a
> > fluke in setup of our boost?  Or perhaps I'm missing some package
> > that should be in BuildRequired.
> > 
> > - Similarly boost math, its contents disappeared.  I'll look into
> > both more closely tomorrow.
> 
> You are right, Boost.Math and Boost.Accumulators are header-only
> components. By the way, to get the exhaustive list of
> (non-header-only) Boost libraries, we can check:
> http://www.boost.org/doc/libs/1_41_0/more/getting_started/unix-variants.html#header-only-libraries
> 
> It thus means that we should not package separately the header-only
> components. From what I understand, that means that we should remove
> the boost-accumulators and boost-math sub-packages (all the other
> sub-packages have got actual libraries).

Agreed that this is the solution.
 
> > - I think we can drop the license at the core "boost" package.
> > Each sub-package carries its own license, which is as it should be
> > (placing it to core package might seem to make the most sense, but
> > then you could install one of the "leaves" and end up
> > license-less).    

Seems sensible.

> By the way, if we remove the license file from the "boost" package,
> that latter will become empty (and rpmlint reports that as an error).
> Since the "boost" package is an umbrella, should we keep it empty
> (and handle the rpmlint error as an exception),

Yes. This seems fine to me.

> I've begun to draft a Feature Request for Fedora 13:
> https://fedoraproject.org/wiki/Features/F13Boost141#Detailed_Description
> Do not hesitate to contribute.

Thanks for starting this. If we are all agreed as to the shape of things
then I will wait for a Petr build in Koji with these things as
discussed, and then when I see that I'll send mail to the fedora-devel
list with the PLAN and rebuild requests, starting Friday noon PST? I
should send the mail 24 hrs in advance of the actual rebuild probably.
Comment 34 Benjamin Kosnik 2010-01-14 02:08:01 EST
Hey y'all. I updated the Wiki page so that all the sections are filled in, all i's dotted, t's crossed. We can just refer to this in the announce mail, so make sure it's correct. Serious, but not too serious.
Comment 35 Petr Machata 2010-01-14 07:56:17 EST
(In reply to comment #33)
> > > - I dropped the soname patch, now that we've agreed about the
> > > soname naming convention.
> > 
> > That patch is convenient for testing on Fedora 11 & 12
> 
> I also prefer to include the actual patch in the SRPM, but not activate
> it. That was the plan with attaching the patch but not %patching it.

Ok, so be it.

> > You are right, Boost.Math and Boost.Accumulators are header-only
> > components.
> > 
> > It thus means that we should not package separately the header-only
> > components. From what I understand, that means that we should remove
> > the boost-accumulators and boost-math sub-packages.

About math.  It was already shipped in F 12.  Even if there are no dependencies on math in F 13, as will be the case after rebuild, what would happen during yum-assisted update from F 12 to F 13 is that boost-math would stay on the "old" version.  That shouldn't break the update path though, I think, and I don't really see which other subpackage should obsolete boost-math.

> > By the way, if we remove the license file from the "boost" package,
> > that latter will become empty (and rpmlint reports that as an error).
> > Since the "boost" package is an umbrella, should we keep it empty
> > (and handle the rpmlint error as an exception),
> 
> Yes. This seems fine to me.

Same here.
Comment 36 Petr Machata 2010-01-14 09:48:44 EST
About BOOST_INSTALL_LIB_SUBDIR_NAME.  This mail from the thread that you've (Denis) referenced earlier:
  http://lists.boost.org/boost-cmake/2009/10/0661.php
... shows a patch that adds support for LIB_SUFFIX.  The %cmake macro on my F 12 installation already passes that option to cmake.  I tried to simply drop the magic, and the library directory turned out to be lib64, just as it should.
Comment 37 Denis Arnaud 2010-01-14 10:49:37 EST
Created attachment 383704 [details]
Spec file for Boost 1.41.0-1.1
Comment 38 Petr Machata 2010-01-14 11:02:59 EST
similarly with -DCMAKE_INSTALL_PREFIX=%{_prefix}.  The %cmake macro passes -DCMAKE_INSTALL_PREFIX:PATH=%{_prefix}.  That seems close enough to my untrained eye, and indeed the build still passes on i686 and x8664.
http://koji.fedoraproject.org/koji/taskinfo?taskID=1921108
... and the paths are correct.

Ok, I'll put it all together into srpm, and wait for comments if any.  But unless anyone has a bright idea about the math subpackage, I think we are pretty much ready to commit this in devel.  I'll do that tomorrow around noon UTC unless I hear back otherwise.
Comment 39 Denis Arnaud 2010-01-14 11:41:02 EST
Created attachment 383719 [details]
boost-1.41.0-1.1 for Boost.MPI Python support kept separate
Comment 40 Denis Arnaud 2010-01-14 11:43:28 EST
(In reply to comment #36)
I've successfully tested, on both 32bit and 64bit architectures (with Fedora 12), the newly attached specification file (https://bugzilla.redhat.com/attachment.cgi?id=383719, for boost-1.41.0-1.1), which takes into account both Benjamin's and Petr's latest remarks.

[For information, the discussion, on the Boost-CMake list, about lib64 standard support, occurred here: http://lists.boost.org/boost-cmake/2009/11/0746.php (and referenced KDE4 use: http://lists.boost.org/boost-cmake/2009/10/0670.php)]

Moreover, I've split the Boost.MPI sub-package in two: boost-mpi for just the boost_mpi[-mt].so library, and boost-mpi-python for Python support (i.e., the boost_mpi_python[-mt].so library), as not every developer needing Boost.MPI will also need Python support.

(In reply to comment #38)
> Ok, I'll put it all together into srpm, and wait for comments if any.  But
> unless anyone has a bright idea about the math subpackage, I think we are
> pretty much ready to commit this in devel.  I'll do that tomorrow around noon
> UTC unless I hear back otherwise.    

That sounds great!
Comment 41 Denis Arnaud 2010-01-14 16:00:55 EST
(In reply to comment #38)
> But unless anyone has a bright idea about the math sub-package...

Why not use the "Obsoletes:" tag?
I'd add something like:
-----------
Provides: boost-math = %{version}-%{release}
Obsoletes: boost-math < 1.41.0
-----------

By the way, should we keep the following directives?
-----------
Provides: boost-doc = %{version}-%{release}
Obsoletes: boost-doc < 1.30.2
Provides: boost-python = %{version}-%{release}
Obsoletes: boost-python < 1.30.2
-----------
Comment 42 Petr Machata 2010-01-15 07:02:22 EST
Sure, but which package should obsolete the math package?  None of the "leaf" packages makes sense, and if it's the umbrella package, it will drag in whole boost just because the user had the math subpackage...
Then again leaving old boost-math around is not kosher either, what with all the mysterious link errors that are bound to turn up because of that.

The boost-doc and boost-python directives are probably irrelevant by now, and given that they are listed at the umbrella package, even wrong now that we ship boost-python again.  I guess let's just drop them.
Comment 43 Petr Machata 2010-01-15 11:41:18 EST
I've commited to rawhide.  I didn't yet tag and build it.

I decided to leave boost-math in after all, the prospect of leaving obsolete DSO and package makes me uneasy.  The package is empty at the moment, its only purpose is to erase boost-math DSOs, and that's what its documentation says.  Since boost-math can be installed as sole package, without other boost packages, this is the only way that I see to remove obsolete crud from the user's system.  We can consider turning that subpackage into a more general-purpose obsoleting subpackage, called boost-obsolete or something.  Or dropping it in F 15 on the basis that update from F 12 to F 15 is not supported anyway.
Comment 44 Denis Arnaud 2010-01-15 18:42:34 EST
Created attachment 384742 [details]
boost-1.41.0-2.1
Comment 45 Denis Arnaud 2010-01-15 18:49:25 EST
(In reply to comment #43)
> I've commited to rawhide.

The version you took was not the last I attached (the Boost.MPI, for instance, was not split in boost-mpi and boost-mpi-python). So, I've re-applied the corresponding changes to your latest version (boost-1.41.0-2), giving version 1.41.0-2.1 (https://bugzilla.redhat.com/attachment.cgi?id=384742).

[I could not commit into CVS, as I've not the access rights for now (https://admin.fedoraproject.org/pkgdb/packages/name/boost)]

> I decided to leave boost-math in after all, the prospect of leaving obsolete
> DSO and package makes me uneasy.

That's fine for me.

-----
I noticed that the potential SONAME patch set the soname version to 6, whereas it is equal to 5 in Fedora 12. As that patch is intended for compatibility with current Boost versions on Fedora 12, shouldn't the soname version of that patch be 5 (rather than 6)?
Comment 46 Petr Machata 2010-01-18 09:56:24 EST
(In reply to comment #45)
> The version you took was not the last I attached (the Boost.MPI, for instance,
> was not split in boost-mpi and boost-mpi-python). So, I've re-applied the
> corresponding changes to your latest version (boost-1.41.0-2), giving version
> 1.41.0-2.1 (https://bugzilla.redhat.com/attachment.cgi?id=384742).

I'm sorry, I missed that change.  I'm looking at your attachment 384742 [details], and am wondering why do we want boost-mpi-python in the first place.  The file list is missing, the package will end up empty.  If the currently-suppressed mpi.so is the reason, we can add the sub-package later, when the file is fixed.

> I noticed that the potential SONAME patch set the soname version to 6, whereas
> it is equal to 5 in Fedora 12. As that patch is intended for compatibility with
> current Boost versions on Fedora 12, shouldn't the soname version of that patch
> be 5 (rather than 6)?    

My POV is that ABI-incompatible libraries should have different sonames.  But I don't use that patch personally and can't really judge what's the best default here, so I'll leave to you and Benjamin to settle.
Comment 47 Denis Arnaud 2010-01-18 13:32:39 EST
Created attachment 385184 [details]
Spec file for Boost 1.41.0-2.2
Comment 48 Denis Arnaud 2010-01-18 13:33:23 EST
Created attachment 385185 [details]
Patch used by the spec file for Boost-1.41.0-2.2
Comment 49 Denis Arnaud 2010-01-18 13:41:46 EST
(In reply to comment #46)
> I'm sorry, I missed that change.  I'm looking at your attachment 384742 [details], and am wondering why do we want boost-mpi-python in the first place.  
> The file list is missing, the package will end up empty.  
> If the currently-suppressed mpi.so is the reason, we can add the sub-package 
> later, when the file is fixed.

Sorry, that was a typo. In the newly attached specification, the file list has been added as it should be.

> My POV is that ABI-incompatible libraries should have different sonames.  But I
> don't use that patch personally and can't really judge what's the best default
> here, so I'll leave to you and Benjamin to settle.    

I do not know what Benjamin will prefer. All what I can say is that I have been testing that solution (SONAME of 5 on Fedora 12) for a few weeks by now, and everything works well. So, even though upstream Boost can not guarantee a full ABI compatibility, it seems to work for a few important libraries (e.g., date-time, program-options, spirit, serialization, graph).
So, for anyone wanting to upgrade to Boost-1.41.0 on Fedora 12 without having too many troubles, it should be just fine (I would not push it for everyone, though).
Comment 50 Petr Machata 2010-01-19 11:23:57 EST
Regarding the soname selection, I've made the solution as it was before.  The soname patch became a meta-patch that's made into real patch by sed, and then always applied.  In most cases that means the the patching ends up being an effective nop, but I don't personally mind that, at least the soname selection is now simple and uniform.

Selection of "sonamever" variable (dispatch to F-13 vs. earlier) is taken from your version of the spec.  The comment was adjusted to fit the new situation.  File lists were adjusted so that %{sonamever} appears everywhere that it should.  I did a scratch build with %{sonamever} of 5 and peeked in a couple RPMs to make sure everything is in its place.

boost-mpi-python is in, taken from your spec.

I tagged 1.41.0-3.fc13 and built it.
Comment 51 Petr Machata 2010-01-19 11:26:00 EST
By "as before" I mean before the cmake port.  The SONAME patch used to be a meta-patch just as it is now.
Comment 52 Denis Arnaud 2010-01-19 15:06:47 EST
(In reply to comment #50)
> Regarding the soname selection, I've made the solution as it was before.  The
> soname patch became a meta-patch that's made into real patch by sed, and then
> always applied. In most cases that means the the patching ends up being an
> effective nop, but I don't personally mind that, at least the soname selection
> is now simple and uniform.

That sounds good for me (the only thing is that rpmlint cannot detect that the patch is applied and thus reports a warning on it).

> I tagged 1.41.0-3.fc13 and built it.    

That's perfect. I've built the Boost packages for Fedora 12 for both i686 and x86_64 architectures, updated my own Yum repository accordingly, and now use that version without any issue.

So, it seems we almost made it! Will you push the Feature Request (https://fedoraproject.org/wiki/Features/F13Boost141) to Fesco?
Comment 53 Petr Machata 2010-01-20 06:34:04 EST
I've added a link to this bug and moved the Feature page to FeatureReadyForWrangler category.
Comment 54 Denis Arnaud 2010-02-03 13:22:03 EST
Petr Machata has released the new Boost package (where the libraries have been split up) for rawhide (https://bugzilla.redhat.com/show_bug.cgi?id=559009#c45), which therefore closes that enhancement request.

For information, the rawhide build is here: http://koji.fedoraproject.org/koji/taskinfo?taskID=1960702

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