On Fri, 2015-06-05 at 10:34 +0200, Dodji Seketeli wrote: > 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. Just to clarify, this isn't about the karma *count*, it's about whether a package can be pushed to stable automatically when it reaches the karma threshold or if it requires a conscious decision by the maintainer to push it. This will present backwards-incompatible changes from going to stable *accidentally*. (There are cases where they are permissible, such as security patches or ABI changes that are coordinated with all their consumers). > 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. > Yes, this would be the ideal situation. > 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=r > efs/heads/sinny/abipkgdiff Since it wasn't covered in the original email: This first step is limited to C and C++ ABI (basically ELF binaries). Long-term, the goal would be to develop and implement ABI checking for a variety of other languages, but those tools are not yet readily available (or if they are, we don't know about them. So please educate us!)
Attachment:
signature.asc
Description: This is a digitally signed message part
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
