On 2026-01-28 8:24 AM, Vít Ondruch wrote:
On the consumer / requires side, the generator could see what symbols are required by library / executable, e.g. `_dl_find_object`, and if `$ rpm -q --whatprovides 'libc.so.6(_dl_find_object)(64bit)'` was successful, then it would insert the require into the package. Of course this would need to be enabled by e.g. `BR: elfdep-symbol-requires-generator` similarly to the provides generator.
There are a couple of things that make that approach a little more complex than it sounds. An ELF binary has a lit of the shared objects that it needs, and it has a list of symbols that it needs, but the symbols aren't directly linked to a shared object. The symbols within shared objects may not be unique, either. For example, fgetxattr is defined in both libc.so.6 and libattr.so.1. If there are similar cases in libraries without symbol versions, it may not be clear what dependency to output for any required symbol.
At the beginning, we could enable this just for combination of packages which we figure are problematic. In later stages, we could optimize this. For example, if there was .symbols / .map file available in repo, when the symbols are generated, the amount of generated provides could be reduced.
Just like the symbols themselves, if a capability "provided" by an rpm package is removed, then it is no longer backward compatible with the packages that it use to support. Removing a feature is a breaking change.
So, for example, if libattr.so.1 did not have versioned symbols and the package provided 'libattr.so.1(fgetxattr)(64bit)', then a binary package would require 'libattr.so.1(fgetxattr)(64bit)'. Then, if a future build of libattr.so.1 *did* have versioned symbols and the package provided 'libattr.so.1(ATTR_1.0)(64bit)' instead, all of the binary packages that had been built that required the symbol capabilities wouldn't be compatible with this new package.
If we add new capabilities via the dependency generator, it has to be something that the packages will continue to provide in all future (backward-compatible) releases. Adding versioned symbols is a backward compatible change, so we would want the package capabilities to evolve in a backward compatible manner, too.
That's why I think using a version number, either the one provided by the DSO's canonical path, or the one provided by the rpm, is a better option than symbol deps. Symbol deps are better in that you don't raise the required version of each library *unnecessarily*, but the metadata becomes *huge*. If they were on by default, the dnf metadata would be easily 10x larger. A version number means dependencies get more strict, but they can be on by default and they'll perform well.
-- _______________________________________________ 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://forge.fedoraproject.org/infra/tickets/issues/new
