On Sun, Feb 19, 2023 at 1:22 AM Gordon Messmer <gordon.messmer(a)gmail.com> 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