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 _______________________________________________ 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
