F23 System Wide Change: Boost 1.59 Uplift
= Proposed System Wide Change: Boost 1.59 Uplift =
https://fedoraproject.org/wiki/Changes/F23Boost159
Change owner(s): Jon Wakely <jwakely redhat com>
This change brings Boost 1.58.0 or later to Fedora 23. We generally aim to ship 1.59.0, as
that seems likely to make it (hence the Change name), but 1.58.0 is out and available now.
== Detailed Description ==
The aim is to synchronize Fedora with the most recent Boost release. Because ABI stability
is one of explicit Boost non-goals, this entails rebuilding of all dependent packages.
This has also always entailed yours truly assisting maintainers of client packages in
decoding cryptic boostese seen in output from g++. Such care is to be expected this time
around as well.
Boost 1.59 does not have firm schedule yet. I do not think there is even a provisional
schedule at this point. We may have to package Boost 1.58 instead.
Here is the Fedora 22 Change, should you need it.
== Scope ==
Rebasing Boost has a fairly large impact on Fedora. For Fedora 20, the scope was: about
130 packages _must_ be rebuilt due to ABI breakage inherent in bumping Boost sonames.
There were almost 250 client packages total. I expect these numbers to stay in the same
ballpark for Fedora 23.
* Proposal owners:
** Build will be done with Boost.Build v2 (which is upstream-sanctioned way of building
Boost)
** Request a "boost" build system tag (discussion) (take a look at the ticket
#6093 for inspiration)
** Build boost into that tag (take a look at the build #606493 for inspiration)
** Post a request for rebuilds to fedora-devel (XXX link to fedora-devel message here)
** Work on rebuilding dependent packages in the tag.
** When most is done, re-tag all the packages to rawhide
** Watch fedora-devel and assist in rebuilding broken Boost clients (by fixing the
client, or Boost).
* Other developers: Those who depend on Boost DSO's will have to rebuild their
packages. Feature owners will alleviate some of this work as indicated above, and will
assist those whose packages fail to build in debugging them.
* Release engineering: Side tag creation.
* Policies and guidelines: Apart from scope, this is business as usual, so no policies, no
guidelines.
--
Jan Kuřík