Fedora 21 Boost 1.56 Uplift
This change brings Boost 1.56.0 (or, failing that, Boost 1.55.0) to Fedora 21.
- Name: Petr Machata
- Email: pmachata redhat com
- Release notes owner:
- Backup contact, co-maintainer: Denis Arnaud
- Targeted release: Fedora 21
- Last updated: 2014-04-07
- Tracker bug: <will be assigned by the Wrangler>
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.56 doesn't have firm schedule yet. Current provisional schedule (published [| here]) talks about May 5 2014, which would give us enough time to package Boost 1.56. But we may have to package Boost 1.55 instead.
Here is the Fedora 20 Change, should you need it.
Benefit to Fedora
Fedora will stay relevant, as far as Boost clients are concerned. Boost 1.55 brings a new library Boost.Predef.
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 largely the same for Fedora 21.
- 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) (tag request ticket)
- Build boost into that tag (e.g., build)
- Post a request for rebuilds to fedora-devel (e.g., message)
- 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.
No impact on system upgrade.
Some impact on other packages. Historically this hasn't been too big a problem and could always be resolved before deadline.
How To Test
- No special hardware is needed.
- Integration testing simply consists of installing Boost packages (
yum install boost) on Fedora and checking that it does not break other packages (see below for a way to obtain a list of boost clients).
Expected to remain largely the same.
Packages that must be rebuilt:
$ repoquery -s --releasever=rawhide --whatrequires libboost\* --disablerepo=* --enablerepo=fedora | sort -u
$ repoquery --releasever=rawhide --archlist=src --whatrequires boost-devel --disablerepo='*' --enablerepo=fedora-source
Historically, coordination was necessary for Python 3 packages that Boost depends on. Similarly if there are deep changes to MPI packages (openmpi, mpich2), we should coordinate.
If we build in a separate tag, the natural result of a catastrophic failure would be shipping Fedora with non-recent Boost.
If we rely on a mass rebuild, we would have to unwind the damage--Release Engineering would untag what succeeded; pmachata would revert Boost rebase; pmachata would fire another round of client rebuilds, rebuild everything against older Boost again. If _that_ fails catastrophically (e.g. new GCC rejects code in old Boost), we are doomed. But really we would patch around this.
- Contingency deadline: Soon after mass rebuild will likely be clear that there's a catastrophic problem.
- Blocks release? Yes if there are client packages that are on installation media.
1.56 wasn't released yet.
Boost has been upgraded to version 1.56.0. Apart from a number of bugfixes, this XXX fill in later when 1.56 is actually out XXX