Dne 31. 01. 26 v 10:10 Gordon Messmer napsal(a):
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.
I wonder how does this look in practice? Are those indistinguishable in lets say objdump output?
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.
I am not worried about this case. We more or less know how to deal with it and the solution is (mass)rebuild. What is important that resolver ensures that users still have a versions which works together, albeit they might be older.
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.
I see your point, but I don't agree that the solution must be backward compatible. After all, we know that at this very moment, we have combination of apps / libraries which are not compatible. Anything is better IMHO. With all due respect, it seems that you are setting the bar too high and therefore we won't have anything.
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.
Versioned symbols are likely better, but if there are no versioned symbols available, the we should have a solution.
BTW since my main domain is Ruby, I am thinking why libruby does not have versioned symbols. And there are (at least) two reasons which I can imagine:
1) Nobody asked yet2) Nobody cares, because the typical us case for most of the people is just use statically linked Ruby, so there is hardly any motivation to look at versioned symbols.
And frankly, despite I could go and try to ask upstream to provide versioned symbols, I'd be actually much happier if Fedora could solve this for Fedora, because asking every upstream is tedious, thankless and neverending work.
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://forge.fedoraproject.org/infra/tickets/issues/new
