Bug 706973

I agree it would be a good idea, though so far I've failed to implement it.
find-debuginfo.sh has some debuginfo splitting support from Roland for kernel and in the past glibc as well, but I can't make it work right.

I've tried:
RPM_BUILD_DIR="/builddir/build/BUILD" RPM_BUILD_ROOT="/builddir/build/BUILDROOT/gcc-4.6.0-8.fc15.x86_64" /usr/lib/rpm/find-debuginfo.sh --strict-build-id -p '/.*/libgcc_s.*' -o debugfiles-base.list -p '.*' -o debugfiles.list /builddir/build/BUILD/gcc-4.6.0-20110525

but that created empty debugfiles.list and debugfiles-base.list contained
just some dirs and libgcc_s*.debug files.  Ideally it would add also
/usr/lib/debug/.build-id/ symlinks and sources.  Guess sources I can handle myself, perhaps the build id as well using debuglinks.list (and assuming it has been created in the build dir), but then I wouldn't be using find-debuginfo.sh splitting support at all.

Created attachment 501125 [details]
gcc.spec.diff

Only very lightly tested patch which
1) splits gcc-debuginfo into gcc-base-debuginfo and gcc-debuginfo
   - gcc-base-debuginfo contains debuginfo stuff (*.debug stuff, .build-id links
     and relevant sources) for just libgcc_s, libgomp and libstdc++, 
     gcc-debuginfo requires gcc-base-debuginfo = %{v}-%{r}
     and contains all the remaining stuff.  More stats about those packages 
     later.
2) to fix libgcc downgrade issues, I'm afraid <lua> is the only solution.
   For %post it uses a statically linked proglet which does essentially
   [ -x /sbin/ldconfig ] && /sbin/ldconfig, because of circular dependencies
   where libgcc can't depend on /sbin/ldconfig being present, when glibc-common
   requires glibc which requires libgcc.  But in %postun the statically linked
   hack might not exist already in the filesystem.

$ ls -l gcc-base-debuginfo-4.6.0-8.fc15.x86_64.rpm gcc-debuginfo-4.6.0-8.fc15.x86_64.rpm 
-rw-rw-r--. 1 jakub mock   1943208 May 26 16:36 gcc-base-debuginfo-4.6.0-8.fc15.1.x86_64.rpm
-rw-rw-r--. 1 jakub mock 137836380 May 26 16:36 gcc-debuginfo-4.6.0-8.fc15.1.x86_64.rpm
$ rpm -qpi gcc-*debuginfo*x86_64.rpm
Name        : gcc-base-debuginfo           Relocations: (not relocatable)
Version     : 4.6.0                             Vendor: (none)
Release     : 8.fc15.1                      Build Date: Thu 26 May 2011 04:31:30 PM CEST
Install Date: (not installed)               Build Host: (none)
Group       : Development/Debug             Source RPM: gcc-4.6.0-8.fc15.1.src.rpm
Size        : 9619806                          License: GPLv3+ and GPLv3+ with exceptions and GPLv2+ with exceptions and LGPLv2+ and BSD
Signature   : (none)
URL         : http://gcc.gnu.org
Summary     : Debug information for libraries from package gcc
Description :
This package provides debug information for libgcc_s, libgomp and
libstdc++ libraries from package gcc.
Debug information is useful when developing applications that use this
package or when debugging this package.
Name        : gcc-debuginfo                Relocations: (not relocatable)
Version     : 4.6.0                             Vendor: (none)
Release     : 8.fc15.1                      Build Date: Thu 26 May 2011 04:31:30 PM CEST
Install Date: (not installed)               Build Host: (none)
Group       : Development/Debug             Source RPM: gcc-4.6.0-8.fc15.1.src.rpm
Size        : 740369160                        License: GPLv3+ and GPLv3+ with exceptions and GPLv2+ with exceptions and LGPLv2+ and BSD
Signature   : (none)
URL         : http://gcc.gnu.org
Summary     : Debug information for package gcc
Description :
This package provides debug information for package gcc.
Debug information is useful when developing applications that use this
package or when debugging this package.

Panu, has the %post{,un} -p <lua> have a reasonable chance to work (in my testing on a dummy spec file it executed /sbin/ldconfig fine after /sbin/ldconfig access check on F15, but I wonder if it can work e.g. for older rpm as well (say RHEL6/F13+).

Plus, any comments on the approach chosen to split the debuginfo package?

Should be done in gcc-4.6.0-9.fc16 in rawhide as well as gcc-4.6.0-9.fc15 in F15 updates testing.  Please test.

Looks good. Thanks!

The problem persists in Fedora 17 with libgcc-4.7.0-5.fc17.x86_64.  166MB of debuginfo just because of libgcc_s.so.1.  This is unreasonably large; there should be only 1 MB or less.

Example:
# debuginfo-install squashfs-tools-4.2-2.fc17.x86_64
Installing:
 gcc-debuginfo   x86_64     4.7.0-5.fc17    fedora-debuginfo      166 M

$ ldd /usr/sbin/mksquashfs
	linux-vdso.so.1 =>  (0x00007fff253c2000)
	libpthread.so.0 => /lib64/libpthread.so.0 (0x0000003e90000000)
	libm.so.6 => /lib64/libm.so.6 (0x0000003e8fc00000)
	libz.so.1 => /lib64/libz.so.1 (0x0000003e90c00000)
	liblzma.so.5 => /lib64/liblzma.so.5 (0x0000003ea3800000)
	liblzo2.so.2 => /lib64/liblzo2.so.2 (0x0000003e91400000)
	libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x0000003e93000000)   <<< HERE
	libc.so.6 => /lib64/libc.so.6 (0x0000003e8f800000)
	/lib64/ld-linux-x86-64.so.2 (0x0000003e8f400000)
	librt.so.1 => /lib64/librt.so.1 (0x0000003e90800000)
$

That is not a gcc bug though, just a missing feature of the debuginfo-install.
Because to get debuginfo of libgcc/libstdc++, it is enough to install just gcc-base-debuginfo, you don't need gcc-debuginfo.

(In reply to comment #7)
> That is not a gcc bug though, just a missing feature of the
> debuginfo-install.
> Because to get debuginfo of libgcc/libstdc++, it is enough to install just
> gcc-base-debuginfo, you don't need gcc-debuginfo.

Adding James to CC so he can comment on the missing feature.

 Not sure how we'd fix that ... there is no explicit relationship between "ABCD" and "XYZ-debuginfo", we basically just use: 

repoquery --qf '%{name} => %{base_package_name}-debuginfo' libgcc
libgcc => gcc-debuginfo
libgcc => gcc-debuginfo

...so atm. the only way to teach anything about multiple debuginfo packages is to have a new base.

There is a problem that binary rpms do not contain --provides info (or any info) on the build-ids contained in them.

But debuginfo-install is normally run only for already installed packages so it could ask for build-ids of files in that binary rpm:
  eu-unstrip -n -e /bin/bash
  0x400000+0x4eaf05 b9d67be78bc8684290a53cae0dab92bd6e5116fc@...
                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
And them:
  yum install /usr/lib/debug/.build-id/b9/d67be78bc8684290a53cae0dab92bd6e5116fc.debug

 If elfutils came with a python module which provided an API to do /bin/bash => /usr/lib/debug/.build-id/b9/d67be78bc8684290a53cae0dab92bd6e5116fc.debug ... then we could certainly add that (at least as an option).
 It would require "guessing" about what to pass into the API, and would require downloading the filelist (on previous suggestions it was suggested that these could be added as buildid(b9d67...) provides, fixing that problem).

 But the biggest problem is doing the /bin/bash => buildid without running a random program and screen scrapping the output.

libdwfl provides fairly straightforward ways to do this.  Feel free to contribute a Python module using it (or general Python bindings).

Historical reference to a related case: bug 700922 where kernel-debug-debuginfo (> 150MB) is downloaded when only info for [vdso] and [vsyscall] are needed.

This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle.
Changing version to '19'.

(As we did not run this process for some time, it could affect also pre-Fedora 19 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.)

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19

The problem persists in Fedora 19.  Analyzing a crash in gnome-shell after install of gnome-shell-debuginfo requests 81 other -debuginfo, including both
  gcc-base-debuginfo-4.8.0-2.fc19.i686   2.6MB (useful and reasonable)
  gcc-debuginfo-4.8.0-2.fc19.i686     206MB (useless and much too large)

This message is a notice that Fedora 19 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 19. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained. Approximately 4 (four) weeks from now this bug will
be closed as EOL if it remains open with a Fedora 'version' of '19'.

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

(In reply to James Antill from comment #11)
>  If elfutils came with a python module which provided an API to do /bin/bash
> => /usr/lib/debug/.build-id/b9/d67be78bc8684290a53cae0dab92bd6e5116fc.debug
> ... then we could certainly add that (at least as an option).
>  It would require "guessing" about what to pass into the API, and would
> require downloading the filelist (on previous suggestions it was suggested
> that these could be added as buildid(b9d67...) provides, fixing that
> problem).
> 
>  But the biggest problem is doing the /bin/bash => buildid without running a
> random program and screen scrapping the output.

eu-unstrip -n is provided explicitly for listing the buildid. I don't think relying on its output is "screen scrapping". The output format is pretty stable and regular (0xaddr0xoffset hexbuildid@0xaddr elffile debugfile).

Programmatically you can open the elf file with libdwfl.h dwfl_begin (), or even simpler using dwfl_standard_argp () and then do something like:

  const unsigned char *id;
  GElf_Addr id_vaddr;
  int id_len = dwfl_module_build_id (mod, &id, &id_vaddr);

Or with elfutils >= 0.159 you don't even have to use the libdwfl library and you can simply use libelf to open the Elf file and then use libdwelf.h:

/* Returns the build ID as found in a NT_GNU_BUILD_ID note from either
   a SHT_NOTE section or from a PT_NOTE segment if the ELF file
   doesn't contain any section headers.  On success a pointer to the
   build ID is written to *BUILDID_P, and the positive length of the
   build ID is returned.  Returns 0 if the ELF lacks a NT_GNU_BUILD_ID
   note.  Returns -1 in case of malformed data or other errors.  */
extern ssize_t dwelf_elf_gnu_build_id (Elf *elf, const void **build_idp);

There are currently no python bindings for the elfutils libraries, but they would certainly be welcome if someone wanted to add them.

yum and related packages are no longer actively developed.
They are being replaced with dnf, dnf-utils, etc.

I'm closing this bug because it's most likely never going to be fixed.
If you still consider your bug report important, reopen it, please.

yum and related packages are no longer actively developed.
They are being replaced with dnf, dnf-utils, etc.

I'm closing this bug because it's most likely never going to be fixed.
If you still consider your bug report important, reopen it, please.