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.
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.
_______________________________________________
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
