Hello, Following up on the ABI checking topic raised in the "API Break Detection" section near the end of the post https://lists.fedoraproject.org/pipermail/server/2015-June/001904.html, I'd like to summarize where we stand at the moment and what we plan do. We discussed this topic on the #fedoral-devel IRC channel yesterday and here is what stuck to my mind. Others are of course welcome to add what I have forgotten and to correct me when I a wrong. To start, we'd like to have an automated way to check the ABI compatibility of binaries embedded in packages that are submitted to the updates-testing repository. When an incompatible change[1] is detected, the package will be prevented from auto-increasing it's karma count. I guess a manual intervention will then be required to increase the karma or a new package version needs to be submitted again. Under the hood, the current informal plan seems to be to come up with a Taskotron checking task, which, for a given package named P, will compare the ABIs of the binaries embedded in P against their counterparts in the latest known stable version of P that is present in the stable repository. The result of the comparison shall be a report showing the ABI difference of the offending binaries, if those changes are deemed harmful or possibly harmful, from an ABI compatibility standpoint. At this moment, we do have a command line tool named "abidiff"[2] that knows how to compare two shared library binaries and emits a report about the differences in their ABI. That tool needs the debug info of the binaries too. We are currently working on a tool named "abipkgdiff"[3] that takes two RPMs and compares the shared library binaries. That tool should be ready enough (hopefully) in the coming days. When the "abipkgdiff" command line tool is ready , I guess the plan is to use it in a new Taskotron task that, when invoked on a given package, gets the stable version of that package as well as the debuginfo packages from koji, executes abipkgdiff to compare the package against it's stable version and emits the resulting report. So, that is the first "baby step" we talked about. There are obviously going to be many other baby steps coming up, and I'll write something about them a little bit later on this topic, possibly in the wiki, rather. Needless to say, even the baby steps in this note need to be refined, I guess we'll do that on the wiki some where. But until then, I thought I'd drop this note to let you know where we stand. Thank you for reading so far. [1]: A change in a the ABI of a shared library is considered "compatible", if an application linked with the older version of the library is still going to function reliably when executed against the newer version of the library, without being re-linked. Otherwise, the ABI change is considered "incompatible". [2]: abidiff manual documentation can be consulted at https://sourceware.org/libabigail/manual/abidiff.html [3]: abipkgdiff is being hacked on by Sinny Kumari in a branch of the upstream libabigail git repo at https://sourceware.org/git/gitweb.cgi?p=libabigail.git;a=shortlog;h=refs/heads/sinny/abipkgdiff -- Dodji -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
