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!)