Re: Feedback wanted for a proposed improvement to RPM's ELF dependency generator

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux