V Sat, Feb 18, 2023 at 09:20:20AM -0800, Gordon Messmer napsal(a):
For shared libraries without versioned symbols, the provides will
change
from:
Provides: libnghttp2.so.14()(64bit)
to:
Provides: libnghttp2.so.14()(64bit) >= 14.24.1
... while requirements on that package will change from:
Requires: libc.so.6(GLIBC_2.3.4)(64bit)
Requires: libnghttp2.so.14()(64bit)
to:
Requires: libc.so.6(GLIBC_2.3.4)(64bit)
Requires: libnghttp2.so.14()(64bit) >= 14.24.1
[...]
Dependencies are generated using dlmopen() to locate a required
library
named in an ELF header, and then resolving the symlink to a full path. If
the full path ends in ".so.x.y.z", where "x.y.z" is a series of
numbers
separated by dots, then the numbers and dots suffix is treated as a version
number for that library.
I applaud the struggle for ensuring compatibility. However, I worry that it
will make downgrading RPM packages less feasible. Imagine a user who updates
a system, finds a regression in a library, attempts to downgrade the library
and it will result into downgrading later-built reverse dependencies only
because the library applied a (wrong) fix and the triplet has changed.
Do you know meaning of the numbers? I only guess that the first number
tracks incompatible changes, the second number tracks added interfaces and the
last number tracks interface-irrelevant changes (fixes usually).
Provided my guess is correctm would it make sense to exclude the last number
from the RPM dependencies? I.e. libnghttp2.so.14.24.1 library file name would
produce "libnghttp2.so.14()(64bit) >= 14.24" dependency. This less strict
approach would provide users a freedom to downgrade/upgrade libaries without
changes in the interface.
-- Petr