Changes/SubpackageAndSourceDebuginfo

Separate Subpackage and Source Debuginfo

Summary

Allow to install just the debuginfo for a subpackage and/or without the source files. The debuginfo packages are huge because they contain debuginfo and all sources for all subpackages. Being able to install only the debuginfo for the subpackage that is installed reduces the size that needs to be downloaded to analyze, trace, profile or debug a program or core file. Some tracing and profiling tools don't need the actual source files to provide stack traces or insert probes. So installing the debugsources should be optional.

Owner

• Name: Mark Wielaard and Neal Gompa
• Email: mjw@fedoraproject.org and ngompa13@gmail.com
• Release notes owner:

Current status

• Targeted release: Fedora 27
• Last updated: 2017-07-17
• Tracker bug: #1421595

There is also a task list in the cloud tracking subtasks: http://taiga.fedorainfracloud.org/project/mjw-better-rpm-debuginfo-package-creation/

All needed support is in upstream rpm at this point, patches being backported to Fedora rpm (4.13).

Detailed Description

Currently both the .debug files and the source files of all subpackages are included in a debuginfo package. This creates huge debuginfo packages with a lot of data that might not be relevant to the user/developer. By splitting out the sources (found under /usr/src/debug) and the .debug file for the separate binaries of the subpackages (under /usr/lib/debug) the amount of data a developer/user needs to install to trace, profile or debug will be greatly reduced.

Other distributions (notably Suse) already split their debuginfo packages this way. We will take those patches (https://build.opensuse.org/package/view_file/openSUSE:Factory/rpm/debugsubpkg.diff) and integrate them into rpm upstream. This will involve two steps: - https://taiga.fedorainfracloud.org/project/mjw-better-rpm-debuginfo-package-creation/us/8 - https://taiga.fedorainfracloud.org/project/mjw-better-rpm-debuginfo-package-creation/us/10

This depends on some of the cleanups introduced by the ParallelInstallableDebuginfo change.

We can either make this work with the current dnf debuginfo-install plugin by providing a meta package that matches the main-debuginfo package which depends on all sub- and source-debuginfo packages. Or we work with the dnf hackers to make dnf debuginfo-install work with sub-debuginfo packages.

A couple of packages already have hand-written sub-debuginfo packages (notably the kernel, glibc and gcc). We will work with those packages to adopt the new standard approach.

Release engineering needs to be involved to see if any changes are necessary for adding the sub-debuginfo/debugsources packages to the repodata.

Benefit to Fedora

This is part of a series of updates to modernize debuginfo and debugsource packages. To coordinate with other distros and set some standards in upstream rpm packaging (and hopefully later for other packaging initiatives that provide users with symbols, debuginfo and sources). Previous updates have pushed all Fedora debuginfo extensions (mini-symtab, gdb-index generator, dwz debuginfo compression support) upstream to be integrated in rpm so other distros can also easily reuse them. This update adds some extensions from suse into upstream rpm and uses them in Fedora. These updates make sure the amount of data users needs to download to trace, profile or debug a program or core file should be a lot less. When this is in place, Fedora will have clean and separate installation paths, and needed subpackages are small the next step would be to provide something like the Clear Linux, All debug information, all the time, feature (as a cross distro standard).

Scope

• Proposal owners: Patches against rpm upstream need to be integrated as outlined in the Detailed Description.
• Other developers: Upstream rpm and dnf maintainers have to review the proposed patches. If accepted the package maintainers will have to decide whether those patches can be backported for the next fedora release. Packages that now split their debuginfo packages by hand might want to change their package to adopt the new (standard) approach. Once all changes are in a package debuginfo needs to be regenerated before it becomes sub-package/source split.

• Release engineering: Needs to be discussed. In theory no changes apart from those listed above are needed. But release engineering might know whether any changes are necessary for adding the sub-debuginfo/debugsources packages to the repodata. Ticket #6863
  • List of deliverables: N/A (Still Unknown)

• Policies and guidelines: No changes, the debuginfo related rpm macros won't change. They will just start producing sub-package debuginfo and debugsources packages once all changes are in place.

• Trademark approval: N/A (not needed for this Change)

Upgrade/compatibility impact

This feature doesn't need a mass rebuild. But before being able to have sub-package debuginfo/debugsources packages need to be rebuild. But having the patches ready before the mass rebuild would help a lot with finding any issues.

How To Test

Unfinished. Running a tracer (systemtap), profiler (pref) or debugger (gdb) against a program or core file should suggest the correct debuginfo/sources packages to install. After that the tracing/profiling/debugging session should work as before.

User Experience

dnf debuginfo-install should be able to install the correct sub-pacakge debuginfo/soruces for a package. Ideally in a way that downloads less data than before. But no other user visible changes should be observed.

Dependencies

See the Detailed Description. A list of package bugs/patches should be added.

Contingency Plan

If we added changes to how the debuginfo packages are generated into rpmbuild and they do turn out not to work correctly with some/most debug/trace/profile programs then we might have to revert those changes.

• Contingency mechanism: Any changes to rpmbuild (rpm macros) need to be reverted and any packages already build might need to be rebuild.
• Contingency deadline: beta freeze
• Blocks release? Unknown Yes/No
• Blocks product? Unknown product

Documentation

Not yet written.