Changes/F20Boost154

Fedora 20 Boost 1.54 Uplift

Summary

This change brings Boost 1.54.X to Fedora 20.

Owner

• Name: Petr Machata
• Email: pmachata redhat com
• Release notes owner:

• Backup contact, co-maintainer: Denis Arnaud
• Backup contact: Benjamin De Kosnik <bkoz redhat com>

Current status

• Targeted release: Fedora 20
• Last updated: 2013-07-03
• Tracker bug:

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 (or just packaging soon enough that a mass rebuild, if any, takes care of this for free). This has also always entailed yours truly assisting maintainers of client packages in decoding cryptic boostese seen in output from frustrated g++. Such care is to be expected this time around as well.

As a side note, there are currently two broad Boost-related ongoing projects: repository modularization, and conversion to CMake. The first doesn't need to concern us, as it's purely upstream issue. Boost will keep being released in a single super-tarball for time to come. The latter may concern us eventually in that will require adjustment of packaging, but that's nowhere near ready yet.

As another side-note, I am considering packaging boost-devel in modules. Frankly, boost-devel is unwieldy. Shipping 1.8MLOC in a single package defies the purpose of packaging. Unlike the abovementioned modularization effort, which is purely upstream, this one is purely in packaging, and wholly separate from upstream. I expect this to be part of Change for Fedora 21.

And finally here is the Fedora 19 Feature request, should you need it.

Benefit to Fedora

Fedora will stay relevant, as far as Boost clients and fanbois are concerned. Boost 1.54 brings three new libraries.

Scope

Rebasing Boost has a fairly large impact on Fedora. About 130 packages _must_ be rebuilt due to ABI breakage inherent in bumping Boost sonames. There are almost 250 client packages total.

• Proposal owners:
  • Build will be done with Boost.Build v2 (which is upstream-sanctioned way of building Boost)
  • Roughly in parallel:
    • Either:
      • If there is mass rebuild for Fedora 20, package Boost before it starts.
      • Otherwise:
        • 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 (unless there is a mass rebuild, then no assistance).

• Policies and guidelines: Apart from scope, this is business as usual, so no policies, no guidelines.

Upgrade/compatibility impact

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 19 and checking that it does not break other packages (see below for a way to obtain a list of boost clients).

User Experience

Expected to remain largely the same.

Dependencies

Packages that must be rebuilt: $ repoquery -s --releasever=rawhide --whatrequires libboost\* --disablerepo=* --enablerepo=fedora | sort -u All clients: $ 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.

Contingency Plan

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. If _that_ fails catastrophically (e.g. new GCC rejects code in old Boost), we are doomed. Realistically, it shouldn't be a problem to patch around this.

• Contingency deadline: This contingency mechanism is rather wobbly, I'm not sure when is the last time this could be invoked.

• Blocks release? Yes if there are client packages that are on installation media.

Documentation

http://www.boost.org/users/history/version_1_54_0.html