On Sat, Jan 28, 2023 at 06:12:11PM -0800, Gordon Messmer wrote: > On 2023-01-28 13:03, Zbigniew Jędrzejewski-Szmek wrote: > > > ...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. > > > The version doesn't have to be major.minor.micro, though. The dependency > generator only needs to get the version of the package that provides the > .so, and use that version. As long as changes within a so version are > always backward compatible, and the so version is bumped when breaking > changes are made (which are already constraints on the existing system), > then the proposed solution is reliable. It's sometimes too strict -- it > might require 1.4.3 when 1.4.0 is compatible -- but it's reliable. OK, it sounds like something worth doing. (One issue that I expect that there'll be some libraries which do "strange things" and may need different handling, so some opt-out mechanism would need to be provided.) > > There is an alternative scheme that is supported by our rpm tooling already: > > symbol versioning. > > > Yes, the enhanced rpm dependencies would only be necessary for libraries > that don't provide versioned symbols (which seems to be the vast majority of > them). > > I don't think convincing hundreds or thousands of developers to add symbol > versioning to their libraries is a viable solution. I'd love to see it > happen, but rpm/dnf should be more reliable in the meantime. Ack. 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
