On 03/05/2018 01:25 AM, Florian Weimer wrote:
On 03/03/2018 12:00 AM, Carlos O'Donell wrote:
You expressed some worry about checking in the tarballs for the frozen ABI specification into dist-git. Really git is not designed to hold tarballs, and the source cache is just wrong since this is not a source tarball (we used to abuse it also for the releng tarball).
We really need the individual input files under version control. Otherwise, changes will impossible to review.
So there has to be a repository somewhere with the data.
Agreed.
There is already a project for ABI checks in Fedora. Could we integrate with that?
This is taskotron. Taskotron already has dist.abicheck, and it is run against glibc using abipkgdiff.
Empirically I think it is too late at taskotron for developer tooling, and I'd like to be able to give us immediate per-patch feedback as we develop our work, particularly if we are going to do more automated patch backporting using our tooling.
I am going to suggest the following, and tell me if you think it is a good solution:
1. Create a pagure.io upstream project called 'glibc-abi' which has serialized ABI details for each target arch we care about, matching one released from upstream: https://sourceware.org/glibc/wiki/ABIList
2. Create branches in 'glibc-abi' which match upstream glibc releases, and also create public Fedora or RHEL branches as required, the ABI is public anyway and serves as a touch-point for anyone wanting to consume metadata about our published ABI (internal and external).
3. Consume tarballs of the 'glibc-abi' branches in downsteram Fedora glibc, RHEL, CentOS etc., so we would have 2 source tarballs (glibc, glibc-abi).
We avoid creating a new package in downstream distros to package the data, we just consume it directly from the glibc-abi branches.
We would discuss, merge, and update glibc-abi project to track the various ABIs of the downstream branched releases.
From a bug tracking perspective we would need to file bugs to rebase the glibc-abi data from upstream if we needed to pull in new data from glibc-abi for say Fedora 28.
Does that make sense?