On Tue, Mar 14, 2017 at 10:02 PM, Stephen Gallagher <sgallagh@xxxxxxxxxx> wrote: > On 03/14/2017 12:15 PM, Zbigniew Jędrzejewski-Szmek wrote: >> On Tue, Mar 14, 2017 at 06:35:17AM -0400, Simo Sorce wrote: >>> On Thu, 2017-03-09 at 15:10 -0800, Adam Williamson wrote: >>>> ldns was updated from 1.6.17 to 1.7.0 for Rawhide and Fedora 26 on >>>> 2017-03-06. This update bumped the soname from libldns.so.1 to >>>> libldns.so.2 . This soname bump was not announced, as it is supposed >>>> to >>>> be, and dependent packages were not rebuilt. >>>> >>>> opendnssec depends on libldns and freeipa-server-dns requires >>>> opendnssec, so this resulted in FreeIPA server deployment - which is >>>> a >>>> core Fedora Server feature, and in the Alpha release requirements - >>>> breaking on both 26 and Rawhide. >>>> >>>> We will now need to go through the blocker process to have the >>>> opendnssec rebuild pulled into Fedora 26 composes, as this >>>> unannounced >>>> soname bump landed right before the Alpha freeze. >>>> >>>> Other packages that depend on libldns appear to be dnssec-trigger and >>>> netresolve. dnssec-trigger has been rebuilt (but will need to go >>>> through the blocker or FE process to make it into 26 Alpha), >>>> netresolve >>>> has not, yet. I will try to rebuild netresolve. >>>> >>>> Once again, folks, *please* announce your soname bumps, and co- >>>> ordinate >>>> rebuilds. >>> >>> Can we simply have a mechanism that blocks packages from going through >>> if a soname bump id detected and an appropriate bugzilla with a >>> specific keyword of SONAMEBUMP is not present, or something like that ? >> There's also the old school technique of specifying the soname in %files: >> >> %global somajor 11 >> %global sominor 2.3 >> %files >> %_libdir/lib%name.so.%soversion.%sominor >> %_libdir/lib%name.so.%soversion >> %files devel >> %_libdir/lib%name.so >> >> And then one cannot do an announcement so-bump by mistake. >> > > The libabigail approach would be more versatile, though. Mostly because > upstreams don't always remember to bump soname when they break compatibility. +1 for using libabigail tooling here. libabigail detects soname changes along with other ABI changes. For example, running libabigail's abipkgdiff tool locally between ldns-1.6.17-20 and ldns-1.7.0-1, we see following results telling soname of libldns has changed: $ abipkgdiff --d1 ldns-debuginfo-1.6.17-20.fc25.x86_64.rpm --d2 ldns-debuginfo-1.7.0-1.fc27.x86_64.rpm --devel1 ldns-devel-1.6.17-20.fc25.x86_64.rpm --devel2 ldns-devel-1.7.0-1.fc27.x86_64.rpm ldns-1.6.17-20.fc25.x86_64.rpm ldns-1.7.0-1.fc27.x86_64.rpm Removed binaries: libldns.so.1.6.17, SONAME: libldns.so.1 Added binaries: libldns.so.2.0.0, SONAME: libldns.so.2 As Dan Horak mentioned, we already run abicheck taskotron task [1] which uses libabigail to detect any sort of ABI changes for a package update (currently runs only for critpath packages). With the help from taskotron devs, we have also extended abicheck run from critpath packages to all packages in dev instance [2]. Soon abicheck task will run on all package updates and result from abicheck will be visible in bodhi package update interface too. [1] https://taskotron.fedoraproject.org/resultsdb/results?testcases=dist.abicheck [2] https://taskotron-dev.fedoraproject.org/resultsdb/results?testcases=dist.abicheck _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx