On Sun, Feb 19, 2023 at 1:22 AM Gordon Messmer <gordon.messmer@xxxxxxxxx> wrote: > > 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. I see, thanks for the clarification! I assumed that you're going to use the RPM version since you're shoving this data inside RPM's standard "<name> <operator> <epoch-version-release>" syntax for Provides / Requires, but if you're using the soversion instead, then the discrepancy between project version and library version doesn't matter. Fabio _______________________________________________ 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
