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 Dependencies section below. Dodji Seketeli is the entry point for the the whole project, though.

• Release notes owner:
• FESCo shepherd:

Current status

• Targeted release: Fedora 23
• 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.

Needed sub tasks breakdown

1. retrieving the "latest stable build" with koji
2. to be continued

Scope

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

For the first version of the system in Fedora 23 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 owners:

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

to check for harmful changes. There is also a new 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:

• Policies and guidelines:

Contingency Plan

• Contingency mechanism:
• Contingency deadline:
• Blocks release? No
• Blocks product? No