On Thu, Jan 15, 2026 at 10:28:56AM -0800, Gordon Messmer wrote: > To the best of my recollection, in all of the conversations I've had with > library developers, the issue hasn't been that they don't know *how* to > export or maintain versioned symbols, it's that they don't know *why* they > should. So while I think that rpm's elfdeps needs to do *something* for > libraries that don't offer versioned symbols, I also think we should write > an explanation of why this matters and advocate the practice to upstream > developers. I can write that, but as an individual I don't think I can > effectively advocate for that change.
Yeah, I think it is fair to say that docs could be somewhat improved in this area, both in terms of how to use it, and why. AFAIR the binutils docs were fairly limited to the low level details. I have a very old blog post about symbol versioning from when we introduced it to libvirt that talks about how it benefits the RPM versioning, and also specifically mentions the backporting concerns https://www.berrange.com/posts/2011/01/13/versioning-in-the-libvirt-library/ but there really ought to be formal docs that cover this kind of thing, not just random blog posts. > > > abidb is a repository of ABI information generated and maintained by the > > > libabigail project. A global DB of files, with symbols and the rpm version > > > in which they first appeared could back a solution that is largely like > > > Debian's approach, but without individual package maintainer overhead > > If this magic is done behind the scenes and thus largely hidden from > > package maintainers, how do we approach the problematic implications of > > cherry-picking of new APIs to old versions ? > > > If we use {version}-(revision} as the dependency expression, I don't think > there's a problem. Even if someone backported one symbol to expat-2.7.1-10, > a package that used that symbol would require "libexpat.so.1()(64bit) >= > 2.7.1-10". Yep, that would appear safe, though there is a very minor weakness in this approach when there are multiple streams. Consider a starting point * Fedora 42: has libfoo.so.1 version 2.0.0-3.fc42 * Fedora 43: has libfoo.so.1version 2.4.0-8.fc43 * Fedora Rawhide: has libfoo.so.1version 3.0.0-1.fc44 And then for some reason a new symbol backport is required from a 3.0.0 API into all stable streams. * Fedora 42: gets new libfoo.so.1 version 2.0.0-4.fc42 * Fedora 43: gets new libfoo.so.1 version 2.4.0-9.fc43 An application built against libfoo.so.1 in the Fedora 42 will get libfoo.so.1()(64bit) >= 2.0.0-4.fc42 That's fine when resolving libfoo.so.1 against F42 repos. That would be satisfied by any version of libfoo.so shipped in F43 repos, regardless of whether it also had the symbol backported or not. Again that's a very minor problem, highly unlikely to affect anything shipped by Fedora. Only 3rd party RPMs that don't rebuild for each Fedora release stream are liable to encounter that. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| -- _______________________________________________ devel mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/[email protected] Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
