On 03/14/2018 09:56 PM, Carlos O'Donell wrote:
On 03/14/2018 09:38 AM, Florian Weimer wrote:
>>> Then the problem is that if you merge from rawhide, you need to
>>> make ABI edits at the same time, and it won't be clear which
>>> changes in the merge commit come from the upstream changes, and
>>> which are due to adjustments of downstream-only (internal) ABI
>>> adjustments as the result of resolving (semantic) merge
>>> conflicts.
>
> Sorry, I meant to write “when we merge changes from upstream master
> into rawhide”.
I see two cases:
(a) Upstream has an abi/ directory.
(b) Upstream does not have an abi/ directory.
I also assume that we will be rebasing rawhide against upstream
master, keeping our changes ahead of the upstream master.
In the case of (a), any downstream changes to the ABI file would
be made in the same individual commits that made changes to code.
So during the rebase you would have to consider just one commit
at a time as you reapplied them to your new rebased position.
If they were just additions, we could simplify this by moving the
additions to <xi:include>'d files that existed only in downstream.
I have filed this RFE
https://sourceware.org/bugzilla/show_bug.cgi?id=22971
In the case of (b) we have several options. My favorite is just
to consider abi/ of rawhide to be the point at which *we* start
tracking ABI, and so nothing special needs to be done until
we get our work upstream and we're in situation (a), using libabigail
upstream to do our ABI tracking instead of our bespoke ad-hoc symbol
lists.
I find (b) rather burdensome because the ABI update has to happen as
part of the merge commit. So you have to do the merge, do a build,
figure out the ABI differences, applied that to the real merge, and then
build again. This is not my idea of a good development process.
Thanks,
Florian