An update about: Checking the ABI of packages submitted to the updates-testing Fedora repository

[Dodji Seketeli]

Kamil Paral <kparal at redhat.com> a écrit:

>> Then, when the package N-udpate-V-R is later submitted to Bodhi, the
>> update creation process would query ResultDB for the result of the
>> relevant ABI check that happened at build time.  The decision to allow
>> an automatic push of the update to stable will depend on the result of
>> that query.
>
> This feature might take some longer time. Until that is in place, the
> results will be visible in ResultsDB for anyone interested in looking
> at them, and hopefully we will start sending out fedmsg in the near
> future, so you can listen for it as well.

Right.

[...]


>> 
>>         * Have a Taskotron task that will use all of the above to
>>           perform the ABI comparison and store the result in
>>           ResultDB.

[...]

>>           I still need to file a tracking issue for this.  I guess I
>>           can file it to Phabricator instance of Taskotron and assign
>>           it to myself?
>
> Sure, you can use "new-check-ideas" project for that. We'll be happy
> to help.

Thanks.

>
>> 
>>         * Write a system wide change proposal for this project.
>
> I don't think that is needed until we're able to stop Bodhi from
> pushing an update (for Koji-based checks).

Right.  I just meant the change proposal to be a kind of sheet of paper
where we write what needs to be done in one place.  It won't be formally
submitted until we are ready -- like what you are suggesting -- of
course.  So I have started it at
https://fedoraproject.org/wiki/Changes/CheckUpdatesABIChanges.  Feel
free to update it too, if you see the need.


>> So this is where we stand at the moment.
>
> Also, one further request was to be able to retrieve a rule whitelist
> from distgit. A relevant discussion is occurring in the packaging
> mailing list ("Packages without a dist tag" subject).

Right.  This was for a refinement further down the road.

Basically, when the first basics checks (checking that public ELF
symbols for exported functions and global variables that are present in
a stable package don't disappear in update packages) are in place, we'll
want to go further and check that the types of exported functions and
variables in update packages mean the same thing as in the initial
stable package.

But then, when you start doing deep comparison of types like that, you
need to support a level of "nuance" in determining if a given ABI change
is harmful or not.  For instance, the same kind of ABI change can be
harmful in the context of a given project, and be harmless in another
project.  So developers (package maintainers) need a way to provide a
kind of white list (or waiver specification) to say "In this particular
case, this ABI change is OK, thank you", so that the tool stops
considering the change as being harmful. abipkgdiff should support the
same kind waiver specification, formally called "suppression
specification" [1] that "abidiff" supports today.

It's those white list we think package developers might want to store in
distgit, per package, and that the abi checking service will eventually
consume, you are right.

But this is for after we have the basics in place :-)

[1]: Suppression specifications are extensively documented at
https://sourceware.org/libabigail/manual/libabigail-concepts.html#suppression-specifications

Cheers,

-- 
		Dodji