On 2026-01-15 5:28 AM, VĂt Ondruch wrote:
Dne 14. 01. 26 v 18:18 Gordon Messmer napsal(a):
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.
Sorry for my ignorance. Probably due to my limited knowledge, I still
fail to understand why this needed to be done in two steps? Why the
symbols can't be gathered during the build, once we have the .so file
available?
Debian's approach requires a symbols file in the dist-git repo. It would
be bundled into the src.rpm. It's part of the input to the build.
"Can't" is probably too strong a word. You could use a known symbol map
and just add any new symbols to a generated symbol map that is included
in the -devel package. But if you do, then its contents aren't
deterministic. The version that's associated with those symbols will be
the package version, so it'll increment on every build. And that's ...
fine, actually, as long as you accept that the install-time dependency
expressions that result from a build root containing that package will
also increment until someone commits that file back into dist-git.
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.
If I was upstream, you'd probably have hard time talking to me due to
my ignorance đ
If Fedora, as a project, agrees on the position that the status quo is
unreliable and we would like broader deployment of versioned symbols, I
am happy to write an explanation of the why and the how.
I will not be the first person to write about how. Debian's man page
links to three separate papers that Ulrich Drepper wrote about versioned
symbols. But those papers are very heavy on the technical
implementation, with some discussion of "why?" when developers want to
change behavior without renaming a symbol, and none of dependency
expressions.
https://manpages.debian.org/trixie/dpkg-dev/dpkg-gensymbols.1.en.html
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.
So why don't have combination? E.g. symbols of first encountered
appearance of `libexpat.so.1()(64bit)` stored in something external to
RPM/DNF metadata and keeping just the additions directly in the RPM?
SemVer principals apply to dependency expressions the same way they
apply to the implementation.
Adding something to the set is backward compatible, but removing
something from the set is not. So you could specify a minimum version
and symbol additions, but only if you can track those symbols in a way
that they will be added to every future build of a library. (Because if
it doesn't, then the new build doesn't satisfy a requirement that other
packages express.)
And in the case of the abidb proposal, where each symbol is listed with
the first package version where it was seen, there's no advantage over
merely specifying that package version as the minimum version.
--
_______________________________________________
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
