[Rpm-maint] [rpm-software-management/rpm] Enhance requires with version information from the build root. (PR #2372)

[Zbigniew Jędrzejewski-Szmek]

A different approach, which wouldn't require calling into `rpm` and dealing with multiple rpms, would be to:
1. change the existing Provides generator for SONAME to use a version: `libcurl.so.4()(64bit)` → `libcurl.so.4()(64bit) = 4.8.0`. I think this would be backwards compatible: because the Provides was unversioned, all existing Requires on that provides must also be unversioned, and would still be satisfied after we add a version. The generator works by examining a file and extracting the SONAME, and it could look for a `.so.<major>.<minor>.<patch>` suffix on the file and use that, if found, for the version.
2. change the existing generator for Requires to do essentially the same in reverse: right now it just uses the stored SONAME, but it could also resolve the SONAME in the file system (like `ldd` does), and add a versioned requires. (`libcurl.so.4()(64bit)` → `libcurl.so.4()(64bit) >= 4.8.0`). 

This would have the following advantages:
- it operates entirely on the file system, doesn't use `rpm` database
- the logic is similar to how we handle SONAME with a level of indirection
- the requirement is actually better, more precise. Instead of tying to the name of the providing package, we actually tie to the library name. If the library is moved to a different package, or there are multiple packages which have compatible libraries, thing will just work.


-- 
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2372#issuecomment-1407762298
You are receiving this because you are subscribed to this thread.

Message ID: <rpm-software-management/rpm/pull/2372/c1407762298 at github.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20230129/7589c136/attachment.html>