So how about starting easy.Lets create new RPM generator, which will generate symbol provides. I think the format could be in form suggested as by Florian. E.g. `libc.so.6(_dl_find_object)(64bit)` or including version `libc.so.6(_dl_find_object@GLIBC_2.35)(64bit)`. To enable this generator, there would need to be `BR: elfdep-symbol-provides-generator`.
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.
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. Later, there could be added BRP script, which would check if the .symbols / .map file still corresponds with the library .so name and if difference is detected, fail the build.
BTW to me, it seems that the .map format is simpler and should be enough. And of course we would provide some simple tooling to generate the .map file.
Vít Dne 20. 01. 26 v 19:10 Vít Ondruch napsal(a):
Dne 16. 01. 26 v 19:18 Pavel Cahyna napsal(a):On Fri, Jan 16, 2026 at 09:55:29AM -0800, Gordon Messmer wrote:On 2026-01-16 8:51 AM, Vít Ondruch wrote: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).The problem with that idea is that eventually you will want those additional symbols to be part of the symbol map. Once they're added, new builds of thelibrary package won't "Provide" them any more, which means it no longer satisfies the dependency expressions of packages that "Require: symbol(libruby,some_additional_symbol)"Sorry if I misunderstood the problem, but if you add them only at the moment when the major version is bumped (the soname changes), it is fine, because the dependency like 'Require: libexpat.so.1()(64bit)' will not be satified anyway (there will be libexpat.so.2()(64bit) instead), no?Yes, this is the way I am also looking at the problem. Vít(Is the problem that for some libraries this moment may be very far in the future or never and the set of new symbols will thus grow without bounds anyway?) Regards, Pavel
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
