On Wed, Jan 14, 2026 at 12:17 PM Gordon Messmer <[email protected]> wrote: > > On 2026-01-14 5:25 AM, Vít Ondruch wrote: > > > > Dne 13. 01. 26 v 21:59 Gordon Messmer napsal(a): > >> > >> rpm's elfdeps should generate "Provides" and "Requires" that include > >> at least a major and minor number. Those numbers could be the major > >> and minor number of the DSO version ("libnghttp2.so.14.28.3" might > >> result in providing "libnghttp2.so.14()(64bit) = 14.28") > > > > Hm, this is thing which comes from upstream. It does not seem to me to > > be generally trustworthy. > > > I'm generally uncomfortable with the idea that Fedora should not trust > upstream by default. > > In all of the bug reports that I have seen related to this problem, the > DSO version was correctly bumped, and using the DSO version in the > dependency generator would have prevented the runtime failure. And if we > *also* add abidiff monitoring for new symbols without a DSO bump, this > approach becomes really pretty reliable: > https://codeberg.org/gordonmessmer/libabigail/commit/9b76082c94ad080af84bf2749c2bcadd1d4bdf8c > > > >> or they could be the version of the rpm in the build root > >> ("libexpat.so.1.11.0" might result in providing > >> "libexpat.so.1()(64bit) = 2.7.2"), or some other version source. > > > > Including RPM version sounds better to me. Not sure if also epoch > > should be included. > > > Yeah, epoch *probably* should be included. > >
I have mixed feelings about whether we should have versions in here by default, but I disagree that we should have RPM epochs or release in here. Ultimately, the only property that should be represented there is the upstream information, which would be the version. Epoch and Release are packager knobs, not upstream knobs. (And someday I'd like to reset the entire distro's set of epochs on system upgrades, but that's a separate conversation...) > >> We could also do what Debian does, and require package maintainers to > >> keep a symbol version map. In this case, after a build, the DSO can > >> be analyzed for new symbols, and those symbols can be added to a file > >> that lists the symbols exported by a shared library and the version > >> in which they first appeared. That file needs to be kept in the > >> package repo, and included in the -devel sub-package. > >> > >> I dislike that approach because it requires extra work from package > >> maintainers, and because the symbol analysis has to be done > >> post-build, which might mean doing another build to include the > >> updated symbol map file. > > > > > > Sorry, can you provide more details here for us uninitiated? 😇 What > > work is needed? Can it be done automatically? > > > Debian has a very concise wiki describing symbols files: > https://wiki.debian.org/UsingSymbolsFiles > > And for a practical example, see: > https://sources.debian.org/src/expat/2.7.3-1/debian/libexpat1.symbols > wherein you can easily find the two symbols that were added to > libexpat.so.1 in version 2.7.2. > > 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. > > Hypothetically: that file could be managed entirely outside of the rpm, > like the abidb proposal, but we'd want to publish it somehow, and we'd > want mock to retrieve them along with dependencies. Anything we do that > isn't included in -devel packages risks becoming tool-specific, > optional, and additional complexity. It risks becoming another reason > not to use rpm. > > > >> It's also nearly identical to the work required to simply add > >> versioned symbols to shared libraries, which is a much better option, > > > > But this needs to be done upstream, doesn't it? > > > 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. > > > >> The abidb is currently around 22GB for Fedora 43 x86_64, but the > >> information needed for the feature can be extracted into an sqlite3 > >> file of roughly 500MB, which can be xz compressed to around 75MB. So > >> the overhead for this tool would be sending an extra 75MB file to > >> every build job, and uncompressing that file before the build, adding > >> another ~ 4s to the runtime. > > > > Maybe the DB could be reduced? Provide just information about the most > > recent version and created during compose? > > > 500MB *is* the reduced version. > > > > Given the earlier example, I still think that we should be able to have: > > ~~~ > > Requires: > > symbol(nghttp2_option_set_no_rfc9113_leading_and_trailing_ws_validation) > > ~~~ > > > Full symbol-level dependency information is very reliable, but the cost > would be huge. > > The 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. > Could we use this to help upstreams develop support for symbol versioning? I think a big part of the reason it's not used is because there aren't really good practices around it to leverage the feature. -- 真実はいつも一つ！/ Always, there's only one truth! -- _______________________________________________ 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
