Changes/CheckUpdatesABIChanges

Check updates for harmful ABI changes

Summary

Package updates that are submitted to a fedora-updates repository should not be automatically pushed to the stable repository when its karma threshold is reached.

Owner

• Name: Dodji Seketeli
• Email: dodji@fedoraproject.org

This project involves several sub-tasks that are to be performed by different people from different teams. Please look at the Intermediate milestones section below. Dodji Seketeli is the entry point for the whole project, though.

• Release notes owner:
• FESCo shepherd:

Current status

• Targeted release: Fedora 24
• Last updated: 2015-06-25
• Tracker bug:

Detailed Description

For each stable package, whenever a new update package is submitted, we want to compare the binaries (mostly C and C++ libraries) contained in the packages to see if there has been any harmful ABI change. By harmful ABI change, we mean any ABI change that might make an application linked with the stable library to stop working correctly with the updated one.

If there has been any harmful ABI change then the update will not be pushed *automatically* to the stable repository when it reaches the karma threshold; rather, it will require a conscious decision by the maintainer; probably a new update which corrects the harmful ABI change.

Benefit to Fedora

By detecting these harmful "ABI Breakages" before the package effectively reaches users, this change helps increase the user-perceived quality of Fedora updates.

Intermediate milestones

1. A command line tool to compare ABIs of binaries in RPMs
2. Support retrieving the "latest stable build" with Koji, within libtaskotron
3. Modify Bodhi to make it queries ResultDB for the result of ABI check on each package update and decide to enable or disable automatic push to stable
4. A Taskotron task that triggers when a build is done in koji, gets the stable package corresponding to the build, compares the ABIs of the binaries in the two packages and stores the result in ResultDB

Scope

We are shooting for a basic set of ABI checks for Fedora 24. As the system matures, we might add more involved checks in upcoming Fedora versions.

For the first version of the system in Fedora 24 we would like to check that symbols that are publicly exported from the stable binaries do not disappear from binaries in the updates. In subsequent refinements of the system we plan to check that functions and variables that are publicly exported in stable binaries "mean the same thing" in the updated binaries. To ensure that these exported entry points mean the same thing, we intend to recursively compare their sub-types and detect potential harmful discrepancies there; all that by looking at the ELF binaries and their associated debug information with the tooling provided by the Libabigail project.

• Proposal and sub-task owners: Complete your tasks.

• Other developers: Just voluntary use the abidiff command line tool on the binaries of your package

to check for harmful changes. There is also a new abipkgdiff command line tool in the works, with which you can start playing to directly compare the ABI of the binaries of your package. Discuss the ABI changes with upstream to see if they are really harmful and to decide the best course of action.

• Release engineering: Help handling the two sub-tasks above related to Koji and Bodhi.

• Policies and guidelines:

Upgrade/compatibility impact

None.

How To Test

Submit a build to Koji and manually inspect the ResultDB results.

Dependencies

Libabigail.

Contingency Plan

Please note that when the system detects a possible ABI issue, the update is not blocked. It's just the automatic update that is disable. So as such, possible disruptions to the update mechanisms are mitigated.

• Contingency mechanism: Disable the querying of ABI checking result from ResultDB, when updates are created in Bodhi.
• Contingency deadline: Beta release date of Fedora 24.
• Blocks release? No
• Blocks product? No