SF Markus Elfring wrote:
I wrote a review bot that compares abi changes in submit/maintenance requests and complains if there are incompatibilities: https://github.com/openSUSE/osc-plugin-factory/tree/master/abichecker
Does this approach depend on data from "DWARF debug information"?
Yes.
It uses the abi-compliance-checker tool which maybe was not necessarily the best choice, let's say it that way :-) It's not as reliable as I had wished for so I so far hesiated to activate it for Factory as is.
Would you like to share any more experiences?
What do you want to know? :-) From the top of my head I remember that we had problems with the results in one product as the debug information created by gcc was sometimes not quite correct so we got false positives. The implementation of abi-compliance-checker is fragile as it relies on parsing output from readelf etc. Also, it loads the full data into RAM so huge packages like libreoffice can make it run OOM. A fundamental problem with only looking at the debug information is that one can't know whether a symbol or structure is part of a public or private API. So some libraries produce false positives. The abi-compliance-checker author also offers a method to evaluate the public headers in order to filter out private symbols. That requires recompiling the software though which is not so straight forward to do in a review bot. The reports abi-compliance-checker creates are quite nice though.
Maybe it's worth investigating the use of libabigail for it at some point.
It seems that both approaches deal with XML files. How similar are the involved data structures (or XML data type definitions/schemas)?
I didn't look into libabigail so I can't tell. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org