Changes/F20Boost154

From FedoraProject

< Changes(Difference between revisions)
Jump to: navigation, search
m (How To Test: "see above" -> "see below")
Line 2: Line 2:
  
 
== Summary ==
 
== Summary ==
This change brings Boost 1.54.X to Fedora 20.
+
This change brings Boost 1.54.0 to Fedora 20.
  
 
== Owner ==
 
== Owner ==
Line 17: Line 17:
 
* Targeted release: [[Releases/20 | Fedora 20]]  
 
* Targeted release: [[Releases/20 | Fedora 20]]  
 
* Last updated: 2013-07-03
 
* Last updated: 2013-07-03
<!-- After the change proposal is accepted by FESCo, tracking bug is created in Bugzilla and linked to this page
 
Bugzilla states meaning as usual:
 
NEW -> change proposal is submitted and announced
 
ASSIGNED -> accepted by FESCo with on going development
 
MODIFIED -> change is substantially done and testable
 
ON_QA -> change is code completed and could be tested in the Beta release (optionally by QA)
 
CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development
 
-->
 
 
* Tracker bug:
 
* Tracker bug:
  
 
== Detailed Description ==
 
== 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.
+
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 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 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.
+
As another side-note, I am considering packaging boost-devel in modules.  Frankly, boost-devel is unwieldy.  Shipping dozens of libraries totaling 1.8MLOC in a single package defies the purpose of packaging.  Unlike the above-mentioned 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 [[Features/F19Boost153|Fedora 19 Feature request]], should you need it.
 
And finally here is the [[Features/F19Boost153|Fedora 19 Feature request]], should you need it.
Line 82: Line 74:
  
 
Packages that must be rebuilt:
 
Packages that must be rebuilt:
 +
 
<code>$ repoquery -s --releasever=rawhide --whatrequires libboost\* --disablerepo=* --enablerepo=fedora | sort -u</code>
 
<code>$ repoquery -s --releasever=rawhide --whatrequires libboost\* --disablerepo=* --enablerepo=fedora | sort -u</code>
 +
 
All clients:
 
All clients:
 +
 
<code>$ repoquery --releasever=rawhide --archlist=src --whatrequires boost-devel --disablerepo='*' --enablerepo=fedora-source</code>
 
<code>$ repoquery --releasever=rawhide --archlist=src --whatrequires boost-devel --disablerepo='*' --enablerepo=fedora-source</code>
  
Line 92: Line 87:
 
If we build in a separate tag, the natural result of a catastrophic failure would be shipping Fedora with non-recent Boost.
 
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.
+
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: This contingency mechanism is rather wobbly, I'm not sure when is the last time this could be invoked.
+
* 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.
 
* Blocks release?  Yes if there are client packages that are on installation media.
Line 104: Line 99:
 
== Release Notes ==
 
== Release Notes ==
  
[[Category:ChangePageIncomplete]]
+
Boost has been upgraded to version 1.54.0.  Apart from a number of bugfixes, this brings in three new libraries: Boost.Log for logging, Boost.TTI for Type Traits Introspection, and Boost.TypeErasure for runtime polymorphism based on concepts.
<!-- When your change proposal page is completed and ready for review and announcement -->
+
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler -->
+
<!-- The Wrangler announces the Change to the devel-announce list and changes the category to Category:ChangeAnnounced (no action required) -->
+
<!-- After review, the Wrangler will move your page to Category:ChangeReadyForFesco... if it still needs more work it will move back to Category:ChangePageIncomplete-->
+
  
<!-- Select proper category, default is Self Contained Change -->
+
[[Category:ChangeReadyForWrangler]]
[[Category:SelfContainedChange]]
+
[[Category:SystemWideChange]]
<!-- [[Category:SystemWideChange]] -->
+

Revision as of 19:29, 4 July 2013

Contents

Fedora 20 Boost 1.54 Uplift

Summary

This change brings Boost 1.54.0 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 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 dozens of libraries totaling 1.8MLOC in a single package defies the purpose of packaging. Unlike the above-mentioned 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 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.

Documentation

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

Release Notes

Boost has been upgraded to version 1.54.0. Apart from a number of bugfixes, this brings in three new libraries: Boost.Log for logging, Boost.TTI for Type Traits Introspection, and Boost.TypeErasure for runtime polymorphism based on concepts.