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?
--
Cheers,
Carlos.