This is actually being found in DNF and YUM on EL 7. Fedora/dnf is the preselected Product/Component when one clicks on a link at https://github.com/rpm-software-management/dnf/wiki/Bug-Reporting to report a bug in DNF. Description of problem: If I use "dnf debuginfo-install" to install the debuginfo packages for a given package and there are dependencies which are subpackages of a superpackage, the superpackage's debuginfo it not installed. Version-Release number of selected component (if applicable): dnf-4.0.9.2-1.el7_6.noarch yum-3.4.3-161.el7.centos.noarch How reproducible: 100% Steps to Reproduce: 1. Find a package that requires librdmacm which comes from rdma-core such as qperf 2. sudo dnf install qperf 3. sudo dnf debuginfo-install qperf or (for better info) 4. sudo debuginfo-install qperf Actual results: Only qperf-debuginfo is installed for both #3 and #4, however using the yum debuginfo-install (as in #4) we can see it does not find some necessary debuginfo packages: Could not find debuginfo pkg for dependency package libibverbs-22.1-3.el7.x86_64 Could not find debuginfo pkg for dependency package librdmacm-22.1-3.el7.x86_64 --> Running transaction check ---> Package qperf-debuginfo.x86_64 0:0.4.9-3.el7 will be installed ---> Package yum-plugin-auto-update-debug-info.noarch 0:1.1.31-53.el7 will be updated ---> Package yum-plugin-auto-update-debug-info.noarch 0:1.1.31-54.el7_8 will be an update --> Finished Dependency Resolution Dependencies Resolved ===================================================================================================================== Package Arch Version Repository Size ===================================================================================================================== Installing: qperf-debuginfo x86_64 0.4.9-3.el7 base-debuginfo 131 k Updating: yum-plugin-auto-update-debug-info noarch 1.1.31-54.el7_8 updates 29 k Transaction Summary ===================================================================================================================== Install 1 Package Upgrade 1 Package Expected results: Should find all relevant debuginfo packages including those that are subpackages. Given that EL7 still uses yum by default and this is affected on that platform, it would be nice to have this fixed there also, as much as you want to consider yum deprecated.
Which packages are you actually expecting to be installed? dnf debuginfo-install qperf installs qperf-debuginfo, there are no other packages to be installed. Are you talking about debuginfo packages for dependencies? The plugin doesn't do that. Also, you should be reporting RHEL bugs against the appropriate RHEL Product, not Fedora.
(In reply to Lukáš Hrázký from comment #1) > Which packages are you actually expecting to be installed? dnf > debuginfo-install qperf installs qperf-debuginfo, there are no other > packages to be installed. Are you talking about debuginfo packages for > dependencies? The plugin doesn't do that. Are you saying that dnf debuginfo-install is not supposed to operate in the same way as yum's debuginfo-install which does seem to want to install dependencies given that it emits the errors: Could not find debuginfo pkg for dependency package libibverbs-22.1-3.el7.x86_64 Could not find debuginfo pkg for dependency package librdmacm-22.1-3.el7.x86_64 during dependency resolution? > Also, you should be reporting RHEL bugs against the appropriate RHEL > Product, not Fedora. I am not reporting this as a RHEL bug but as a DNF/YUM bug per the explanation I introduced the ticket with, which I will repeat here: > This is actually being found in DNF and YUM on EL 7. Fedora/dnf is the preselected Product/Component > when one clicks on a link at https://github.com/rpm-software-management/dnf/wiki/Bug-Reporting to > report a bug in DNF.
(In reply to Brian J. Murrell from comment #2) > Are you saying that dnf debuginfo-install is not supposed to operate in the > same way as yum's debuginfo-install which does seem to want to install > dependencies given that it emits the errors: > > Could not find debuginfo pkg for dependency package > libibverbs-22.1-3.el7.x86_64 > Could not find debuginfo pkg for dependency package > librdmacm-22.1-3.el7.x86_64 > > during dependency resolution? I wouldn't use the word "supposed", as I am not entirely sure what the debuginfo-install plugin is supposed to do, but it doesn't do that at the moment. I'll need to have a look at what yum's debuginfo-install is doing, I'm not familiar with it, sorry. However, note that installing debuginfo packages for all dependencies may not work out as well as you'd expect. I assume you'd want it to pull in debuginfo for the whole dependency tree recursively. For certain packages it can pull in a lot of unnecessary packages, if they actually have dependencies which are not dynamically linked libraries. I'm not entirely sure, but I don't think we have a way to distinguish which dependencies are linked libraries and which are dependencies of another kind. This might be the reason it wasn't implemented in the debuginfo-install plugin. > I am not reporting this as a RHEL bug but as a DNF/YUM bug per the > explanation I introduced the ticket with, which I will repeat here: Allright. The thing is on RHEL 7 you're using a much older version of dnf(-plugins-core) and I initially thought you're reporting an issue I think I've fixed in upstream already (I got mislead by your title mentioning subpackages, where you meant to say dependencies - I'm fixing the title now). If you're reporting a bug against Fedora, it's good to post results of commands from the Fedora version you're reporting against.
This message is a reminder that Fedora 31 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 31 on 2020-11-24. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '31'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 31 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
*** Bug 1708270 has been marked as a duplicate of this bug. ***
This bug appears to have been reported against 'rawhide' during the Fedora 34 development cycle. Changing version to 34.
Any progress here? Maybe to generalize the question a bit, if I have a package foo which links to any number of shared libraries from other packages, in order to have usable stack traces, I would want foo-debuginfo to be installed as well as the debuginfo packages for all shared libraries. It seems most intuitive to me that "dnf debuginfo-install foo" does this dependency resolution and installs all of the necessary packages. But if it won't and/or in the meanwhile, how can the above actually be achieved. Indeed, in writing this, it occurs to me that abrt does this. I wonder if anyone here has any pointers to the process abrt is using to recursively resolve debuginfo packages.
No progress, sorry, this really is very low on the priority list, I think your only hope for the foreseeable future would be a contributed implementation. As I've said in my previous comment, the implementation is complicated by us not really knowing which dependencies are dynamically linked libraries that we need to pull debuginfo for and which dependencies are of other kind. That said I haven't really checked what yum did in this regard, again, low priority, apologies. Another solution (I'm not sure if your use case is simple manual debugging or something more involved) is that gdb on rpm-based systems actually gives you a dnf command to install all the missing debuginfos if it loads a binary for which it is missing. It has a list of all the .so files so it's actually able to give you the exact list of packages you need.
> gdb on rpm-based systems actually gives you a dnf command to install all the missing debuginfos if it loads a binary for which it is missing Indeed. I have most certainly noticed that. I am trying to implement automated core file processing[1] though. I *could* run gdb twice, once to parse out needed debuginfo packages and one to get the actual stack trace. Parsing the output of gdb feels pretty fragile though. I have been burned in the past parsing human-targeted command output -- playing whack-a-mole with arbitrary output format changes, etc. [1] Indeed, I did previously mention abrt and it's ability to do just this. I has been occurring to me that perhaps I should just use abrt rather than trying to re-invent this wheel. I don't think that changes the functionality request for this ticket though. It really would be nice for the user not to have to chase debuginfo dependencies, iteratively, until they get a usable stacktrace.
Here's an example from CentOS 7 where debuginfo-install automatically installs all dependent packages: # debuginfo-install coreutils enabling base-debuginfo base-debuginfo | 2.5 kB 00:00 base-debuginfo/x86_64/primary_db | 2.7 MB 00:01 --> Running transaction check ---> Package acl-debuginfo.x86_64 0:2.2.51-14.el7 will be installed ---> Package attr-debuginfo.x86_64 0:2.4.46-13.el7 will be installed ---> Package coreutils-debuginfo.x86_64 0:8.22-24.el7_9.2 will be installed ---> Package glibc-debuginfo.x86_64 0:2.17-260.el7 will be installed --> Processing Dependency: glibc-debuginfo-common = 2.17-260.el7 for package: glibc-debuginfo-2.17-260.el7.x86_64 ---> Package gmp-debuginfo.x86_64 1:6.0.0-15.el7 will be installed ---> Package libcap-debuginfo.x86_64 0:2.22-9.el7 will be installed ---> Package libselinux-debuginfo.x86_64 0:2.5-14.1.el7 will be installed ---> Package openssl-debuginfo.x86_64 1:1.0.2k-16.el7 will be installed ---> Package yum-plugin-auto-update-debug-info.noarch 0:1.1.31-54.el7_8 will be installed --> Running transaction check ---> Package glibc-debuginfo-common.x86_64 0:2.17-260.el7 will be installed --> Finished Dependency Resolution Dependencies Resolved ================================================================================ Package Arch Version Repository Size ================================================================================ Installing: acl-debuginfo x86_64 2.2.51-14.el7 base-debuginfo 127 k attr-debuginfo x86_64 2.4.46-13.el7 base-debuginfo 74 k coreutils-debuginfo x86_64 8.22-24.el7_9.2 base-debuginfo 3.5 M glibc-debuginfo x86_64 2.17-260.el7 base-debuginfo 9.5 M gmp-debuginfo x86_64 1:6.0.0-15.el7 base-debuginfo 860 k libcap-debuginfo x86_64 2.22-9.el7 base-debuginfo 77 k libselinux-debuginfo x86_64 2.5-14.1.el7 base-debuginfo 749 k openssl-debuginfo x86_64 1:1.0.2k-16.el7 base-debuginfo 4.3 M yum-plugin-auto-update-debug-info noarch 1.1.31-54.el7_8 base 29 k Installing for dependencies: glibc-debuginfo-common x86_64 2.17-260.el7 base-debuginfo 9.6 M Transaction Summary ================================================================================ Install 9 Packages (+1 Dependent package) Total download size: 29 M Installed size: 160 M Unfortunately on CentOS 8 this does not install the dependent debuginfo packages: $ debuginfo-install coreutils-single CentOS Stream 8 - Debuginfo 1.7 MB/s | 32 MB 00:19 Last metadata expiration check: 0:00:24 ago on Thu Dec 16 15:21:19 2021. Dependencies resolved. ================================================================================ Package Arch Version Repository Size ================================================================================ Installing: coreutils-debugsource x86_64 8.30-12.el8 debuginfo 1.0 M coreutils-single-debuginfo x86_64 8.30-12.el8 debuginfo 1.3 M Installing dependencies: coreutils-debuginfo x86_64 8.30-12.el8 debuginfo 4.2 M Transaction Summary ================================================================================ Install 3 Packages Total download size: 6.5 M Installed size: 33 M
Here's the old implementation from Yum: https://github.com/rpm-software-management/yum-utils/blob/05db7ef501fc9d6698935bcc039c83c0761c3be2/debuginfo-install.py
Thanks for the example Ken. I knew I was not imagining this difference between YUM and DNF.
This bug appears to have been reported against 'rawhide' during the Fedora 36 development cycle. Changing version to 36.
Still there on 37
This bug appears to have been reported against 'rawhide' during the Fedora Linux 39 development cycle. Changing version to 39.