Checking the ABI of packages submitted to the updates-testing Fedora repository

[Stephen Gallagher]

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!)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20150605/b1562241/attachment.sig>