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.
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.
--
_______________________________________________
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
