On 2026-01-15 2:39 AM, Daniel P. Berrangé wrote:
On Tue, Jan 13, 2026 at 12:59:31PM -0800, Gordon Messmer wrote:
Another potential drawback is that there are a few cases of interchangeable
implementations of shared libraries in Fedora, and this would impose the
additional requirement that anyone developing a library intended as an
interoperable substitute would need to keep their DSO version in sync with
the other implementations.
We don't need to boil the ocean. There are very few cases of interchangeable
impls. We could simply have a macro to disable the use of automatic versions
for those few packages, and then only concern ourselves with the common case.
We can also allow substitutes to override the version that their shared
library provides.
IMHO ELF symbol versioning is the best solution, but we should not be
maintaining that downstream.
Asking for that is effectively turning package maintainers into software
maintainers of an upstream fork, and IMHO that's beyond the bounds of
what I'd generally consider a downstream package maintainer responsibility.
If they wanted to be software maintainers, then they already have the
freedom to choose to engage in upstream. If they have done so, then they
could also propose adding symbol versioning. If they haven't done this,
we shouldn't ask them to do it downstream only.
I agree with all of that. I don't want to add versioned symbols, as a
downstream build project.
To the best of my recollection, in all of the conversations I've had
with library developers, the issue hasn't been that they don't know
*how* to export or maintain versioned symbols, it's that they don't know
*why* they should. So while I think that rpm's elfdeps needs to do
*something* for libraries that don't offer versioned symbols, I also
think we should write an explanation of why this matters and advocate
the practice to upstream developers. I can write that, but as an
individual I don't think I can effectively advocate for that change.
Also there is a significant trap-door with sym versioning should a
maintainer ever cherry-pick a patch from a newer version that adds
a new API back to an old version.
If you keep the new version in the symbol file, then the RPM deps will
be a lie, as the package only supports 1 API from the new release, not
all APIs.
If you replace it with the old version in the symbol file, then the RPM
deps won't be protecting the upgrade path.
If you replace it with the old version, with an extra "point release"
digit appending, then you've protected the upgrade path, but anything
built against this old version with cherry-pick cannot now be loaded
against the subsequent release with the new symbol version, unless
you keep this duplicate symbol forever.
IMHO this leads to just a few practical approaches
- You *MUST* cherry-pick every single new API from a release,
never a subset of APIs, and keep the new version as the symbol
version
Or
- Simply rebase to the new version entirely
Or
- Never cherry-pick APIs to old releases.
Personally my recommendation is to never cherry-pick APIs under any
circumstances. If something is important enough to need the new
functionality in an existnig release then just rebase.
Again, I agree 100%
abidb is a repository of ABI information generated and maintained by the
libabigail project. A global DB of files, with symbols and the rpm version
in which they first appeared could back a solution that is largely like
Debian's approach, but without individual package maintainer overhead
If this magic is done behind the scenes and thus largely hidden from
package maintainers, how do we approach the problematic implications of
cherry-picking of new APIs to old versions ?
If we use {version}-(revision} as the dependency expression, I don't
think there's a problem. Even if someone backported one symbol to
expat-2.7.1-10, a package that used that symbol would require
"libexpat.so.1()(64bit) >= 2.7.1-10".
The abidb approach doesn't have the same trap-door as versioned symbols
(which I think are good, but shouldn't be used with backported
symbols... versioned symbol sets should be treated as if immutable)
--
_______________________________________________
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
