[Rpm-ecosystem] Improving debuginfo packages

Igor Gnatenko ignatenko at redhat.com
Fri May 20 14:42:03 UTC 2016

CC'ing Jan as he wrote support for RPM's debuginfo for GDB

On Fri, May 20, 2016 at 4:36 PM, Mark Wielaard <mjw at redhat.com> wrote:
> Hi,
> 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:
> https://gnu.wildebeest.org/blog/mjw/2016/02/02/where-are-your-symbols-debuginfo-and-sources/
> 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:
> https://fedoraproject.org/wiki/Changes/ParallelInstallableDebuginfo
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/5D5E6LVXEIEM7HWZTN2277LEVY6QQTJ4/
> 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.
> https://build.opensuse.org/package/view_file/openSUSE:Factory/rpm/debugsubpkg.diff?expand=1
>   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.
> Thanks,
> Mark
> _______________________________________________
> Rpm-ecosystem mailing list
> Rpm-ecosystem at lists.rpm.org
> http://lists.rpm.org/mailman/listinfo/rpm-ecosystem

-Igor Gnatenko

More information about the Rpm-ecosystem mailing list