Description of problem: I was using gdb on rawhide, and noticed the following messages: warning: Unable to open "librpm.so.3" (librpm.so.3: cannot open shared object file: No such file or directory), missing debuginfos notifications will not be displayed ... gdb seems to want to use librpm.so.3, but there was an SO bump and I have /usr/lib64/librpm.so.7. Packages were rebuilt in a mass rebuild, but gdb was not. It seems that gdb should Require (or Recommend) librpm with a specific so version (e.g. librpm.so.7()(64bit)) so that a) the dependency is installed even in minimalistic chroots, b) it is installed in a matching version. Version-Release number of selected component (if applicable): gdb-7.9.90.20150717-7.fc24.x86_64 rpm-libs-4.12.90-3.fc24.x86_64 $ rpm -ql rpm-libs /usr/lib64/librpm.so.7 /usr/lib64/librpm.so.7.0.0 /usr/lib64/librpmio.so.7 /usr/lib64/librpmio.so.7.0.0 /usr/lib64/rpm-plugins
http://pkgs.fedoraproject.org/cgit/gdb.git/commit/?id=ddc0fde6fde9238309396e08025f3473c2ea2ac7 (In reply to Zbigniew Jędrzejewski-Szmek from comment #0) > It seems that gdb should Require (or Recommend) librpm with a specific > so version (e.g. librpm.so.7()(64bit)) 'Recommend' only as it is also a soft (dlopen) dependency of /usr/bin/gdb. BuildRequires: %{_libdir}/librpm.so.%{librpmver} Recommends: rpm-libs%{?_isa} It is a file dependency as I do not see rpm NVR package mapping to the .so version. And I do not see how to make safe mapping to 'librpm.so.7()(64bit)' as on i386 it is 'librpm.so.7'. %{?_isa} is not this kind of suffix. And I have not made Recommends a file dependency as it may require the 'filelists' index of yum/dnf. But I am not sure if /usr/lib*/ requires 'filelists' or not, at least /usr/bin/ does not.
Created attachment 1058424 [details] patch to detect current librpm.so version automatically Thanks for the fast response! You can use elfdeps to craft the dependency. Attached patch detects rpm so version provided by rpm-devel automatically.
Thanks for the patch but I do not like this approach, packaging should know what it builds against.
reason: There is currently no good automatic testing for the librpm functionality so that one notices when the librpm API could break.