On Wed, 2018-04-18 at 17:14 -0500, mcatanz...@gnome.org wrote: > On Wed, Apr 18, 2018 at 3:45 PM, po...@pouar.net wrote: > > Well the minor version and the soname of the library itself changed > > but the > > major version and the sonames of the symlinks pointing to the library > > remained the same. > > The first digit in the soname is what matters. E.g. I have on my > machine libbrotlidec.so.0.6.0 and libbrotlienc.so.0.6.0. If the first 0 > changes to 1, then that signals an ABI break, and libraries that depend > on it need to be rebuilt. We call that a soname bump. If only the last > two digits change, then the update is supposed to be ABI-compatible, > and you don't need to worry about it. > > Sometimes upstreams mess this up, though, so be careful.
This is the most common convention, but it's not invariably true. (Some upstreams *intentionally* do not follow this versioning convention for their sonames, note). What the package dependencies ultimately go by is the soname embedded in the library file itself, which you can find with objdump: [adamw@adam systemd (f28 %)]$ objdump -p /usr/lib64/libbrotlienc.so.1.0.1 | grep SONAME SONAME libbrotlienc.so.1.0.1 as you can see, in the brotli package I have installed currently, things are *not* as you suggest: the actual soname really is 'libbrotlienc.so.1.0.1'. It's not 'libbrotlienc.so.1'. We see this reflected in the package's Provides: [adamw@adam systemd (f28 %)]$ rpm -q --provides brotli brotli = 1.0.1-3.fc28 brotli(x86-64) = 1.0.1-3.fc28 libbrotlicommon.so.1.0.1()(64bit) libbrotlidec.so.1.0.1()(64bit) libbrotlienc.so.1.0.1()(64bit) those last three are the auto-generated soname-based provides, and we can see it in the corresponding auto-generated requires: [adamw@adam systemd (f28 %)]$ sudo dnf repoquery --whatrequires "libbrotlicommon.so.1.0.1()(64bit)" Last metadata expiration check: 0:00:00 ago on Wed 18 Apr 2018 03:20:44 PM PDT. brotli-devel-0:1.0.1-3.fc28.x86_64 php-pecl-http-0:3.2.0~RC1-1.fc28.x86_64 Note however that that's with brotli-1.0.1-3.fc28.x86_64 . In Rawhide, in brotli-1.0.3-1.fc29 , the sonames were changed to be just .so.1 , not .so.1.0.1 or .so.1.0.3 . So if the new 1.0.4 retains the '.so.1' soname, it should not require any rebuilds. The other part of this is that it's ultimately the upstream project's responsibility to change the soname when it needs changing - i.e. when the ABI has changed - and *not* change it when it *doesn't* need changing. Our packaging system assumes that upstreams do this; if they don't, it will give weird results, but if they don't (and downstream packagers don't catch this and adjust for it somehow), weirdness can result (like updates that change the ABI but not the soname, so dependencies are satisfied but the apps suddenly don't actually work any more, or updates that change the soname unnecessarily and require us to do rebuilds that weren't really needed). > > Also 2 fields in BrotliDistanceParams changed positions, > > but I'm not sure whether this is exposed to other packages or not. > > Is the definition exposed in a public header? If so, then that would be > an ABI break, and a soname bump would be required. Looks like > BrotliDistanceParams is an implementation detail that's only declared > in a private header, so it's not part of the API and you probably don't > need to worry about it. AFAICS it's in a private header, so I think the soname properly remained the same and no rebuilds should be needed. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
