On 2023-02-18 15:53, Fabio Valentini wrote:
I see a big hole in that problem (assuming that I understand Things correctly): What happens to packages where this .so.x.y.z pattern does not match their actual version?
In this implementation, there is no relationship between the version of the shared object and the package version.
libnghttp2-1.51.0-1.fc37, for example, will "Provides: libnghttp2.so.14()(64bit) = 14.24.1", and any package that is linked to that shared object will "Requires: libnghttp2.so.14()(64bit) >= 14.24.1"
I have seen many packages that don't follow this pattern, for example, some keep .so.0.0.0 forever and just bump the library name instead of the soname (looking at you, mutter).
That will continue to work more or less as it does today. Mutter will provide "libmutter-11.so.0()(64bit) = 0.0.0" and linked packages will require "libmutter-11.so.0()(64bit) >= 0.0.0". If Mutter bumps the library name, that's a breaking change just like the status quo.
Others bump their soname very rarely, so the library itself might have version 2.3.4 but the soname is still at libfoo.so.1.0.0.
That's also fine, although if they are making any kind of changes to their public interface, then they are failing to indicate that, and we end up in the same situation we're in today. Which is to say that if that library adds new interfaces and later package builds use those interfaces, then there's no information about that dependency and rpm might install software that doesn't actually work.
However, today we deal with that (as curl does) by checking package versions during the build and more or less manually doing what this proposed change would do automatically. In the future, we might deal with that by pushing the upstream developers to actually provide information about their interface versions. If not through versioned symbols, then *at least* through giving libtool a version number.
The opposite also happens, with packages bumping soname basically with every release, so libfoo 0.11.2 can provide libfoo.so.143.0.0 ...
If they're incrementing from libfoo.so.142.0.0 (and, consequently, libfoo.so.142) to libfoo.so.143.0.0 (libfoo.so.143), then that's a breaking change both today and in the proposed system.
_______________________________________________ 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
