On Sat, Jan 28, 2023 at 12:12:40PM -0800, Gordon Messmer wrote:
> On  2023-01-28 10:22, Gordon Messmer wrote:
> > In order for rpm to do this, you'd probably have to throw out the
> > current implementation of dependency resolution that provides
> > "libfoo.so.2()(64bit)" and instead provide a dependency like "(foo-libs
> > >= 2.4 with foo-libs < 3)", at least for the cases where libraries do
> > not provide versioned symbols
> 
> ...or "(libfoo.so.2()(64bit) with foo-libs >= x.y.z)", where x.y.z is the
> version of the package that provides libfoo.so.2 in the build root, which is
> an idea that's growing on me.

This is indeed a shortcoming in the rpm symbol dependency generation scheme.
But there's a problem with the proposed approach: versioning as 
major.minor.micro
is just a convention, and not all upstream follow it.

There is an alternative scheme that is supported by our rpm tooling already:
symbol versioning. This is ultimately more powerful, because it allows depending
on specific versions of functions, and not just one monotonic version that
tries to describe anything. (glibc makes extensive use of this to provide
backwards comaptiblity…)

Since symbol versioning is more powerful and pretty well handled by rpm,
I think it's better to try to convince upstream to switch to that if they
change symbols a lot.

(Or even better, in my personal opinion, is to never change SOVERSION, i.e.
to never remove symbols. It is surprisingly easy to provide backwards compat,
for most project much less hassle than to deal with SOVERSION changes and
forced rebuilds.)

Zbyszek
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Reply via email to