On 2026-01-15 1:55 AM, Florian Weimer wrote:
* Gordon Messmer:
## Approaches to consider:
We could use the DSO version, extracted from the symlink. In this
case, the expat-2.7.3 package would provide "libexpat.so.1()(64bit) =
1.11.1" and any package that links to libexpat.so.1 would require
"libexpat.so.1()(64bit) >= 1.11.1"
I don't think that's a good approach because upstreams do not
necessarily maintain these version numbers in a way that makes this
version check meaningful.
The proposed implementation uses the full DSO version, so the only thing
the upstream could do that would invalidate the dependency expression is
not update the version at all. Hypothetically, that's possible. And a
fairly small number of shared objects don't provide a version, so
they're just ".so.0.0.0".
However, all of the bug reports that I've seen related to unresolved
symbols caused by rpm's unversioned dependency expressions would have
been prevented if DSO versions had been used.
This solution is imperfect, but even if we call it a "90% solution"
that's still a huge improvement over the status quo.
We need a way to override upstream versioning decisions without having
to alter the ABI at the ELF level.
One option is the one that developers use today, which is to add a
Require tag to the dependent package specifying the minimum version of
the dependency.
One drawback to this approach is that a dependent binary package would
require expat 2.7.3, even if they did not use any of the symbols that
are new in that version, relative to expat-2.7.1. Some users might
want to build on a system with expat-2.7.3 and deploy on a system with
expat-2.7.1, as long as the binary is able to execute. Adding a more
specific version to the requirement would result in dnf updating expat
when the new binary is installed.
For Fedora, this doesn't seem to be much of a problem because due to
various factors, most software has to be built in a version-specific
buildroot. Portable binaries need to be built outside of Fedora.
I don't think it will meet developer expectations downstream, though.
I'm unclear on whether you mean that the status quo is not a problem
(which I would disagree with), or whether the proposed solution would
not be a problem.
It's also nearly identical to the work required to simply add
versioned symbols to shared libraries, which is a much better option,
and doing the same amount of work to get a result that isn't as good
doesn't make sense to me.
Not all build systems support this in a convenient way, and doing it
downstream only would make the binaries Fedora-specific.
I definitely would not want to do this downstream. That would be a
terrible idea.
I'm just not sure why Debian chose to do effectively all of the work of
adding versioned symbols, but not to push those changes upstream where
they would be most useful.
--
_______________________________________________
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
