Bug 1494628 - The dnf debuginfo-install plugin should also install the -debugsources package
Summary: The dnf debuginfo-install plugin should also install the -debugsources package
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: dnf-plugins-core
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: rpm-software-management
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-09-22 16:47 UTC by Mark Wielaard
Modified: 2018-11-28 19:05 UTC (History)
13 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-11-28 19:05:16 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Mark Wielaard 2017-09-22 16:47:44 UTC
In Fedora 27 debuginfo packages have been split up into subpackages and separate debugsources packages. See https://fedoraproject.org//wiki/Changes/SubpackageAndSourceDebuginfo

The following two patches make sure that dnf and the debuginfo-install dnf plugin  also pick up the debugsources:

One to base dnf to return the correct debug source package name:

--- dnf/package.py.orig	2017-09-14 17:01:59.017810658 +0200
+++ dnf/package.py	2017-09-14 17:45:33.992366055 +0200
@@ -103,7 +103,7 @@
         returns name of debuginfo package for source package of given package
         e.g. krb5-libs -> krb5-debuginfo
         """
-        return "{}-debuginfo".format(self.source_name)
+        return "{}-debugsource".format(self.source_name)
 
     @property
     def source_name(self):

And one to the debuginfo-install dnf plugin to not abort too early when looking for all available debug packages:

--- dnf-plugins/debuginfo-install.py.orig	2017-09-14 17:44:26.624875885 +0200
+++ dnf-plugins/debuginfo-install.py	2017-09-14 17:44:47.672404171 +0200
@@ -98,7 +98,7 @@
     def _di_install(self, package):
         for dbgname in [package.debug_name, package.source_debug_name]:
             if dbgname in self.dbgdone:
-                break
+                continue
             if self._dbg_available(dbgname, package, True):
                 di = "{0}-{1}:{2}-{3}.{4}".format(
                     dbgname,

Comment 2 Mark Wielaard 2017-10-20 11:05:30 UTC
We discussed briefly on irc the other day.

Igor believes a better solution is rpmbuild creating Recommends from the debuginfo to debugsource to pull them in. Which is indeed nice and upstream rpm now does this, but all of f27 is build without Recommends, so this patch is still relevant for f27.

He also mentioned that the patch is not (completely?) correct. But I don't in which situations it does the wrong thing. An example of how the change does the wrong thing (and what would be expected instead) would be appreciated if that is the case.

Comment 3 Lukas Slebodnik 2017-10-20 13:12:42 UTC
(In reply to Mark Wielaard from comment #2)
> We discussed briefly on irc the other day.
> 
> Igor believes a better solution is rpmbuild creating Recommends from the
> debuginfo to debugsource to pull them in. Which is indeed nice and upstream
> rpm now does this, but all of f27 is build without Recommends, so this patch
> is still relevant for f27.
>

And it would require mass rebuild with new version of rpmbuild. 
 
I hope it will be fixed quite soon. Because ATM debugging many things are really complicated.

* it is not possible to install debugsource packages with "dnf debuginfo-install" 
* enabling all debug repositories is slow due to expiration
* manually enabling subset of right repositories is bad UX comparing to f26

Comment 4 Jan Pokorný [poki] 2017-10-26 20:50:29 UTC
Also needed for rawhide (at least for packages derived from f27?).

Comment 5 Sergio Durigan Junior 2018-01-10 14:58:03 UTC
(In reply to Mark Wielaard from comment #2)
> We discussed briefly on irc the other day.
> 
> Igor believes a better solution is rpmbuild creating Recommends from the
> debuginfo to debugsource to pull them in. Which is indeed nice and upstream
> rpm now does this, but all of f27 is build without Recommends, so this patch
> is still relevant for f27.

OOC, why Recommends and not Requires?  Is there any real world scenario where it is actually a good thing not to install the debugsource if the debuginfo is installed?  I'm mostly concerned about when dnf supports Recommends in a Debian-like way, i.e., not really installing the dependencies, but only listing them (which, according to <https://fedoraproject.org/wiki/Packaging:WeakDependencies>, might happen in the future).

Comment 6 Mark Wielaard 2018-01-10 15:04:45 UTC
(In reply to Sergio Durigan Junior from comment #5)
> OOC, why Recommends and not Requires?  Is there any real world scenario
> where it is actually a good thing not to install the debugsource if the
> debuginfo is installed?

Tracing and profiling tools often don't need the actual sources. Since you don't do interactive debugging. For example with systemtap you set probes on functions or statements which it resolves through the debuginfo DWARF data. It doesn't need the actual source files and installing them would only waste space.

Comment 7 Lukas Berk 2018-01-10 15:07:31 UTC
I was hit by this yesterday as well, and was confused as to why running `debuginfo-install foo` no longer installed the appropriate src files to aid in debugging my issue.  This seems like a regression from established behaviour.  Please consider applying Mark's patch.

Comment 8 Sergio Durigan Junior 2018-01-10 19:15:02 UTC
(In reply to Mark Wielaard from comment #6)
> Tracing and profiling tools often don't need the actual sources. Since you
> don't do interactive debugging. For example with systemtap you set probes on
> functions or statements which it resolves through the debuginfo DWARF data.
> It doesn't need the actual source files and installing them would only waste
> space.

That's true.  Even though the debugsource files are generally smaller than the debuginfo ones, I assume your decision is that it's not always interesting to do the Requires thing.  IMHO it _is_ actually interesting to do that (I think of how many people install the debuginfo to trace vs. to debug), but as long as dnf installs Requires deps automatically, I'm fine.

Thanks, Mark.

Comment 9 Samuel Sieb 2018-01-10 19:48:14 UTC
What about adding a new command "debugsource-install"?

Comment 10 Lukas Slebodnik 2018-01-11 10:09:51 UTC
I agree that we still need a solution. It is true that rpmbuild was updated to create recommends But there was not any mass rebuilds. And people still can have disabled installation of weak dependency by default.

e.g.
sh$ wget --quiet https://kojipkgs.fedoraproject.org//packages/libtalloc/2.1.10/5.fc28/x86_64/libtalloc-debuginfo-2.1.10-5.fc28.x86_64.rpm
sh$ rpm -qp --recommends ./libtalloc-debuginfo-2.1.10-5.fc28.x86_64.rpm 
libtalloc-debugsource(x86-64) = 2.1.10-5.fc28

sh$ wget --quiet https://kojipkgs.fedoraproject.org//packages/check/0.11.0/3.fc27/x86_64/check-debuginfo-0.11.0-3.fc27.x86_64.rpm
sh$ rpm -qp --recommends ./check-debuginfo-0.11.0-3.fc27.x86_64.rpm 
sh$

Comment 11 Jan Kratochvil 2018-05-15 08:54:33 UTC
To make it more fun, there is an infrastructure+releng problem of F-28 that even if the debuginfo tools were perfectly working the server repositories are empty.

It has been bugreported on #fedora-admin to puiterwijk and adrianr.
Also:

fedora-debuginfo has wrong (commented) baseurl
https://bugzilla.redhat.com/show_bug.cgi?id=1578301

Comment 12 Christian Stadelmann 2018-10-08 13:08:37 UTC
On Fedora 29 Beta, when running `dnf debuginfo-install [packagename]`, the -debugsource subpackage is always being pulled in by weak dependencies. This is a good compromise and sufficient for my needs. Doesn't this fix the issue?

Comment 13 Lukas Slebodnik 2018-10-12 18:41:29 UTC
(In reply to Christian Stadelmann from comment #12)
> On Fedora 29 Beta, when running `dnf debuginfo-install [packagename]`, the
> -debugsource subpackage is always being pulled in by weak dependencies. This
> is a good compromise and sufficient for my needs. Doesn't this fix the issue?

It does not work is you have weak dependencies are disabled by default in dnf.conf

Comment 14 Ben Cotton 2018-11-27 14:02:11 UTC
This message is a reminder that Fedora 27 is nearing its end of life.
On 2018-Nov-30  Fedora will stop maintaining and issuing updates for
Fedora 27. 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 '27'.

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 27 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.

Comment 15 Mark Wielaard 2018-11-28 19:05:16 UTC
Fedora 27 was never fixed :{
But based on comment #12 and comment #13 I think we can call this resolved for Fedora 29.


Note You need to log in before you can comment on or make changes to this bug.