[Rpm-ecosystem] Improving debuginfo packages

Mark Wielaard mjw at redhat.com
Fri May 20 14:36:08 UTC 2016


We just had a discussion on irc.freenode.net #rpm.org and people
suggested I posted to this list to ask for feedback on what I am working
on and to get feedback on what others are looking for as debuginfo
package improvements.

I work on tracing, debugging and profiling tools like elfutils,
systemtap, valgrind, etc. Which all benefit from having full symbol
tables, debuginfo and sources available. At Fosdem this year I gave an
overview of issues I think packagers/packaging systems should consider
to make things more observable to users:

Some of the recommendations described in that talk are already
implemented in Fedora. And I posted some patches to rpm-maint to get
mini-symtab and dwz DWARF debuginfo compression into upstream rpm.

To solve one of the issues that currently is causing some trouble in
Fedora I just posted a change proposal for Parallel Installable
Debuginfo for consideration in Fedora 25:

The aim is to tweak thing in the -debuginfo package so that you can have
multiple versions installed in parallel. This will help making observing
a 32bit program running on a 64bit architecture possible (currently
because of "coloring" you might not even get a conflict but an
inconsistent set of .debug file), introspecting packages running in
containers that might have different versions installed than the host
system and analysing coredumps of older or newer programs than are
installed on the main system.

The change proposal page above has a list of issues to solve which I
believe are all possible with not too complicated fixes that should be
backwards compatible.

When discussing the above on irc people pointed out some other things
about debuginfo packages that could be improved.

- debuginfo-subpackages. Suse has some patches to create a debuginfo
  package for each main binary package. Instead of one debuginfo package
  per source rpm. This would make it possible to only install the
  actually needed debuginfo.
  I think it makes sense to try to pull this into upstream rpm.

- Dependencies by Build-Id. Debian debs provide the Build-Id for each
  ELF file (executable, shared library, etc) in the package. And similar
  for their debug packages. This makes it easy request the matching
  debuginfo package for a main package. I think it make sense to somehow
  add that to rpm too. Then you could easily request a package or debug
  package based on build-id directly. Currently that is possible if you
  have a file list and can resolve a request for
  the /usr/lib/debug/.build-id/XX/YYYYY.debug file.
  But that is somewhat cumbersome.

- Suppress or split build sources from debuginfo package.
  Not all debuginfo consumers also need the full build sources.
  So it might make sense to split off the build sources into
  a separate -debugsrc package (which the -debuginfo could recommend).

- Not providing build sources at all.
  I don't actually think this is a good idea.
  But it should be easy to provide a simple flag for a package to not
  include them. Currently you need to provide your own
  __debug_install_post macro which is cumbersome.
  It could just be a new flag for find-debuginfo.sh.

Please let me know if any of the above sounds (in)sane, and/or if there
are other debuginfo package issues I am forgetting that could be
improved in rpm.



More information about the Rpm-ecosystem mailing list