V Mon, Feb 20, 2023 at 11:04:43AM +0000, Zbigniew Jędrzejewski-Szmek napsal(a): > 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. > That's all true, but I as a user do not want trade-offs. Imagine a library and an application which uses the library. Both get fixed, but for independent reasons: The library for an miniscule bug, the application for a security bug. After the upgrade, a regression is found in the library which prevents the user from using the application. Now the user stands in front of a dilemma: Should he downgrade both library and the application to get his system working again, but becoming vulnerable, or should he keep it malfcuntioned and waiting on an upstream fix? Consider that delivering the fix can take weeks. Without the overstrict versioning the user would simply downgrade the library, his system would stay safe and functioning. Another example is bisecting build root when locating a regression causeing a build/test failure. The proposed one-way compatibily will unnecessarily complicate it: Instead of simply downgrading changed packages, you will be, in addition, forced to rebuild all reverse dependencies. For me it sound like throwing out a baby with the bath water. -- Petr
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ 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
