On Mon, Feb 20, 2023 at 11:06:10AM +0100, Petr Pisar wrote:
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).
Such use is what the libtool docs and other guidelines recommend.
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.
This is true, with this proposal implemented in full, the user will be forced to
install at least the same .x.y.z versions of dependecies as that against which
the package was built. This is limiting to some extent, but I think the overall
quality will be higher.
Note that the .z number reflects "fixes". When the package is built against
that
version, it is also *tested* against that version. Configuration-time tests,
tests in %check, and autoqa / CI tests would all be done against that version,
and since testers who have updates-testing enabling would also generally install
the full package set, so they would also usually test the latest versions of
all dependencies. I don't think we want to test against the latest version with
all the fixes but then provide a much looser version dependency for users.
If the upsteam is doing a good job, higher .z numbers should be stricly better
than the lower ones.
Zbyszek