On Mon, Feb 20, 2023 at 11:04:43AM +0000, Zbigniew Jędrzejewski-Szmek wrote: > 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. Replying to myself… probably not a good sign. After pressing "send" I realized the following: On Fri, Feb 17, 2023 at 07:03:26PM -0800, Gordon Messmer wrote: > This change would make manual, selected versioned dependencies unnecessary > by generating them automatically for any package that provides libtool-style > versioned shared objects. (Though, again, objects that provide versioned > symbols are excluded, because versioned symbols are already handled > properly, and are the preferred mechanism.) This creates a mismatch in how strictly we handle libs with versioned symbols and those without. Symbol versioning only describes the version of the library when the symbol was introduced, which corresponds to the x.y part of the file suffix. The .z part (patch level) is not reflected at all. With the proposed generator, we'll now treat dependencies without symbol versioning more strictly, because the generator will specify >=x.y.z. For dependencies with symbol versioning, we get the equivalent of >=x.y. I'm not sure what we should do. If the goal is provide the equivalent solution for non-symbol-versioned deps as for symbol-version-deps, then as Petr suggested, ignoring .z in the requirements would be appropriate. This is enough to fix the linker errors described as the motivation. OTOH, as I wrote above, I think that there are good reasons to use the stricter versioning… In that case, I think we should consider enhancing the generator for versioned symbols to use versions: -Provides: libsystemd.so.0(LIBSYSTEMD_209) +Provides: libsystemd.so.0(LIBSYSTEMD_209) = 0.34.0 and: -Requires: libsystemd.so.0(LIBSYSTEMD_209) +Requires: libsystemd.so.0(LIBSYSTEMD_209) >= 0.34.0 The good part is that the Provides side should use the full version, as there is not reason not to. The decision whether to use >=x.y or >=x.y.z in Requires can be delayed until later, when that part of the generator is actually enabled. 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
