Debugging packages in Debian
Vincent Bernat
October 2013
Why do we need debug packages?
- Debug symbols are stripped from binaries to save space
- Using gdb to debug a program
- Getting meaningful backtraces in crash reports
- Debugging a live production system with user-space probing (e.g SystemTap)
Current situation
- Debugging packages are prefixed with
-dbg - Most debug packages are for libraries
-
Package maintainer must explicitely create those
packages (we have more than 2000 of them now). That is
usually quite easy:
- Ensure the package is built with debug symbols
(
-g) - Declare debug package
in
debian/control - Call
dh_strip --dbg-package=foo-dbg
- Ensure the package is built with debug symbols
(
If that's easy, why not automate it?
Source: monkeywing on Flickr
CC BY 2.0
CC BY 2.0
The Ubuntu case
- Provide debug packages for all arch-dependent packages in a dedicated repository
pkg-create-dbgsympackage provides an automatic wrapper arounddh_strip- PPA can optionally provide debug packages too
- If a package ships a
-dbgpackage, the debug package will just depends on it
The Fedora case
- Provide debug packages for all arch-dependent packages in a dedicated repository
- Source code is provided in debug packages
redhat-rpm-configwill add some RPM macros to automatically generate debuginfo packages
Haven't we already discussed that?
Source: monkeywing on Flickr
CC BY 2.0
CC BY 2.0
Prior efforts
- A prior implementation
with
debug.debian.net. Not available anymore. Used a whole archive rebuild to provide debug symbols. - Bug #508585. No much discussion.
- A
first discussion
started by Steve McIntyre about the size
of
-dbgpackages. Everybody agreed on the usefulness of providing debug packages. Some concerns for space (may be mitigated with the use of XZ compression). - A wiki page by Emilio Pozuelo. Good summary. No discussion.
- Another discussion I started, focused on automatic debug packages. Again, everybody agreed on the usefulness.
What are we waiting for?
Source: Neil McIntosh on Flickr
CC BY 2.0
CC BY 2.0
Task list
- Teach
dh_stripto build debug packages automatically (from a certain compat version, using a dedicated flag or if some special file is present) - Adapt tools to handle those packages (the same way they
handle udebs):
aptand friendssbuild,pbuilder, ...dakand the like (reprepro, ...)
- Setup a separate repository (with a different mirror policy)
- Try to not harm reproductible build project by normalizing the debug paths
Not on the task list
- Do source uploads
- Try to have 100% coverage.
debhelperonly is good enough