Rex Dieter wrote: > Pierre-Yves Chibon wrote: >> 1. dist.abicheck - to make sure the update's ABI remains stable in a >> given Fedora release. > > I think it unwise to make item 1 a mandatory item at this point. I'd > argue a large number of packages do not provide public api/abi that's > worth worrying about in this regard. +1 See: https://pagure.io/fesco/issue/1810#comment-488673 https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx/message/UVMM7O4OEGCNMZ47HN7QYPQDIV2IJZFR/ I wrote there: > Uh, `dist.abicheck` produces a lot of false positives on: > > * libraries that are internal and that nothing should depend on (e.g., in > QupZilla, package `qupzilla`), > * APIs explicitly documented as "private, can change at any version", as > common in all Qt modules (e.g., in QtWebEngine, package > `qt5-qtwebengine`). > > My packages often fail `dist.abicheck`. It is absolutely not realistic to > expect it to pass for all updates. I don't think gating on this test will EVER be a reasonable thing to do. It has just too many false positives. There is no automated way to figure out which ABIs are intended to be public and which aren't. And even an API "public" at package level can be private at distro level. (Consider a library with exactly one package using it. It is always reasonable to bump those together in a grouped update. We have several such examples in Fedora.) Adam Williamson wrote: > Additionally, as Ralph wrote, he has removed abicheck from the list of > gating tests for now, so you shouldn't need to worry about abicheck > failures blocking updates, as soon as Bodhi starts applying that > change. FYI, it looks like this is already working. (The other thread said it'd take only up to 6 hours for Bodhi to pick it up, and indeed, qt5-qtwebengine is now showing as passing the gating even though it "fails" the bogus abicheck test.) But why was this check enabled to begin with, when the issues were already known (see the above links)? I get the feeling that I am talking to a wall! Kevin Kofler _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
