On Sun, Jan 29, 2023 at 12:23:49AM +0100, Fabio Valentini wrote:
> On Sun, Jan 29, 2023 at 12:03 AM Zbigniew Jędrzejewski-Szmek
> <zbyszek@xxxxxxxxx> wrote:
> >
> > On Sat, Jan 28, 2023 at 01:49:17PM -0800, Kevin Fenzi wrote:
> > > On Sat, Jan 28, 2023 at 09:03:35PM +0000, Zbigniew Jędrzejewski-Szmek wrote:
> > > >
> > > > This is indeed a shortcoming in the rpm symbol dependency generation scheme.
> > >
> > > Is it though? I'm probibly reading this too quickly and missing
> > > something, but isn't the underlying problem here that nghttp2 changed
> > > abi and didn't change soname? If they had, soup would have kept the
> > > older version around, or asked to upgrade both libsoup and libnghttp2?
> >
> > No. libnghttp2 added one symbol, and (correctly, i.e. following the usual
> > practice), it changed the suffix from .so.14.23.0 to .so.14.24.1. (The last
> > number is bumped when the implementation of existing symbols changes, the middle
> > one when when new symbols are added, and the first one when an incompatible
> > change happens, i.e. symbols are removed or changed incompatibly. Lower numbers
> > are reset to zero whenever a higher one changes.) The SOVERSION corresponds to
> > the major number and does not change in the case under discussion.
> >
> > As Gordon wrote, our rpm dependency generation logic does not care about the
> > minor or patch numbers.
>
> If I understand things correctly, this is not entirely true. RPM
> generates a dependency for the soname / soversion, and some projects
> include not only X, but all of X.Y.Z in that, which RPM will happily
> generate Provides / Requires for (whether that's a nice thing to do
> for an upstream project or whether that's a bug in their build systems
> I leave as an exercise to the reader).
That is all true. But it's probably not a good idea to for the upstream
projects to do that, because the SONAME is used to load the library at runtime. (*)
If the SONAME changes, all programs and libraries linking to that library
need to be recompiled/relinked. This would essentially defeat the shared library
system.
(*) Or more precisely speaking, when a library is installed in the file system,
a symlink is created to the real name (e.g. libcurl.so.4.8.0) from the embedded
SONAME. Subsequently, a program that wants a given SONAME is run, the dynamic
linker looks for the SONAME in the file system and finds the symlink
(libcurl.so.4 in this case) and uses that. IIUC, the SONAME isn't actually
checked again. So SONAME is _not_ used at runtime directly, but it's still used
to set things up so that the library is found.
Earlier, when a program is being compiled, a similar indirection happens. The
compiler/linker is given a library name (e.g. -lcurl) and uses that to locate
the library as %{_libdir}/libcurl.so, reads the SONAME (libcurl.so.4) from that
file and saves the SONAME in the linked program.
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
