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@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue