Dne 15. 01. 26 v 20:26 Gordon Messmer napsal(a):
On 2026-01-15 5:28 AM, Vít Ondruch wrote:Dne 14. 01. 26 v 18:18 Gordon Messmer napsal(a):I expect that it would be possible to automate running gensymbols, and sending a PR to include the results in the dist-git repo, but that's still something that happens after a build, which the developer needs to approve and maintain. And since that data is needed when building packages that depend on the libraries, it should be in the devel package, which means that when it updates, the package should be built a second time to include the updated symbols file.Sorry for my ignorance. Probably due to my limited knowledge, I still fail to understand why this needed to be done in two steps? Why the symbols can't be gathered during the build, once we have the .so file available?Debian's approach requires a symbols file in the dist-git repo. It would be bundled into the src.rpm. It's part of the input to the build.
Ahaaa, I think I start to understand now. So the .map file is actually embedded into the .so library. But that is not what we need IMHO. It is just nice to have.
"Can't" is probably too strong a word. You could use a known symbol map and just add any new symbols to a generated symbol map that is included in the -devel package. But if you do, then its contents aren't deterministic. The version that's associated with those symbols will be the package version, so it'll increment on every build. And that's ... fine, actually, as long as you accept that the install-time dependency expressions that result from a build root containing that package will also increment until someone commits that file back into dist-git.Yes, but that's where it *should* be done. "Upstream first" is a core value. I don't think "it would require collaboration with upstream" should be a reason not to do something.If I was upstream, you'd probably have hard time talking to me due to my ignorance 😇If Fedora, as a project, agrees on the position that the status quo is unreliable and we would like broader deployment of versioned symbols, I am happy to write an explanation of the why and the how.I will not be the first person to write about how. Debian's man page links to three separate papers that Ulrich Drepper wrote about versioned symbols. But those papers are very heavy on the technical implementation, with some discussion of "why?" when developers want to change behavior without renaming a symbol, and none of dependency expressions.https://manpages.debian.org/trixie/dpkg-dev/dpkg-gensymbols.1.en.htmlThe 500MB abidb file is basically just a list of symbols that appear in shared libraries that don't use versioned symbols. For dependency resolution, you'd have to include versioned symbols as well (or else a library could not add symbol versions later, and I think we want them to do that!). That version of the DB would be closer to 1.3GB. And that's just the symbols provided. Once we add the list of symbols required, that metadata would be much much larger. All of that data would have to exist in the yum metadata, and in addition to an explosion in storage and data transfer, it would make dependency resolution much slower during dnf install/update operations.So why don't have combination? E.g. symbols of first encountered appearance of `libexpat.so.1()(64bit)` stored in something external to RPM/DNF metadata and keeping just the additions directly in the RPM?SemVer principals apply to dependency expressions the same way they apply to the implementation.Adding something to the set is backward compatible, but removing something from the set is not. So you could specify a minimum version and symbol additions, but only if you can track those symbols in a way that they will be added to every future build of a library. (Because if it doesn't, then the new build doesn't satisfy a requirement that other packages express.)And in the case of the abidb proposal, where each symbol is listed with the first package version where it was seen, there's no advantage over merely specifying that package version as the minimum version.
So let me make a proposal. Working or Ruby, it seems that libruby does not provide versioned symbols, am I right?
To fix this, we could do something like this on the library side:1) Introduce the .map file similar to the one from the Debian into the repo / SRPM, containing symbols of the library when the .soname was bumped.
2) After the actual libruby.so is built, export the symbols. Whatever is available on top of the .map file inject into RPM metadata as 'Provides: symbol(libruby,some_additional_symbol)' (or whatever is good format).
And now on the app side using the library, check what symbols are required from the libruby. If the freshly build requires something provided by libruby, then inject `Requires: symbol(libruby,some_additional_symbol)`.
Could this work? I think so. The beauty of this approach would be that we could introduce this gradually, if maintainer wishes or when needed. And if it works, enable it everywhere?
I think this could work for libraries which does not properly version symbols upstream, but also for those which does so.
And I also think that we could use the abidb and get rid of the .map files. It depends ....
But again, I don't know if it would not blow the metadata. I have just checked the .map file of Ruby 3.3.0 in Debian and there were added ~250 symbols. Is this too much?
Vít
OpenPGP_signature.asc
Description: OpenPGP digital signature
-- _______________________________________________ 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
