On Mon, Aug 06, 2018 at 09:30:39AM +0200, Guido Aulisi wrote: > Hi, > recently serd library changed its ABI adding 1 function without > bumping the soname. > I think adding one function should not be a problem for depending > packages, what do you think about it? The change is backwards compatible, so programs linked with the older library will run without issue with the newer library. But programs linked with the newer library might crash when run with the older library (if the program uses the new symbol, it will fail during symbol resolution). Looking at serd, it does not use versioned symbols [1], so there's nothing to tell rpm that a package compiled against the newer lib cannot be installed with the older lib [*]. If the new package is just in rawhide, it's probably OK to assume that packages will be updated at the same time. However, if serd were to be updated in released Fedora, and then some depend package was rebuild against the new serd and an update was released for it, users might install just that update without updating serd, and the app could then crash at startup. So serd should not be updated in F28 or lower without additional precautions. [1] https://www.gnu.org/software/gnulib/manual/html_node/LD-Version-Scripts.html [2] I'm out of my depth here, and would love for somebody who understands this to fill in the details: I see three types of libraries: - libraries that use symbol versioning like libsystemd. Then each new symbol that is added get's it's own version, and this translates into generated Provides: $ /usr/lib/rpm/elfdeps -P /usr/lib64/libsystemd.so.0.19.0 libsystemd.so.0(LIBSYSTEMD_209)(64bit) libsystemd.so.0(LIBSYSTEMD_211)(64bit) ... libsystemd.so.0()(64bit) That is clear, because then dependent packages require a specific version, e.g. $ rpm -qR xtide | grep systemd libsystemd.so.0()(64bit) libsystemd.so.0(LIBSYSTEMD_209)(64bit) - libraries that use just a single-number so-version. Then rpmdeps generates Provides based on DT_SONAME. serd seems to fall into this category, because it is linked as [11/13] Linking build/libserd-0.so ['/usr/lib64/ccache/gcc', '-shared', '-Wl,-h,libserd-0.so.0', 'src/byte_source.c.3.o', 'src/env.c.3.o', 'src/n3.c.3.o', 'src/node.c.3.o', 'src/reader.c.3.o', 'src/string.c.3.o', 'src/uri.c.3.o', 'src/writer.c.3.o', '-o/var/tmp/serd/serd-0.30.0/build/libserd-0.so', '-Wl,-Bstatic', '-Wl,-Bdynamic', '-lm'] $ rpm -qP serd | grep libserd libserd-0.so.0 libserd-0.so.0()(64bit) - but then there are libraries which use major-minor-patchlevel versioning, as described in https://autotools.io/libtool/version.html. But afaics, only the major number, i.e. the so-version finds reflection in the executables which link to this library, and there's also no difference in Provides. For example: $ cat a_out.c int main() {return 0;} $ gcc -Wall a_out.c -o a_out -lmikmod $ /usr/lib/rpm/elfdeps -R ./a_out | grep mikmod libmikmod.so.3()(64bit) So libmikmod has a minor-patchlevel version of .3.0, but seemingly no use is made of this. Am I missing something? Zbyszek _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx/message/BGMXR2F57A5RYYXTPFYCEJALCXAYWHGH/
