automatically produce debuginfo packages (like RPM does)

[James Henstridge]

When building an RPM package, rather than stripping the programs and libraries,
RPM separates the debug information into a separate file (stored in
/usr/lib/debug). If the build creates any separated debug information, then
this automatically placed in a separate "debuginfo" pacakge, along with any
source files referenced by the debug information.

This means that you can debug crashes and other problems just by installing the
debuginfo packages, rather than using alternative binaries that have been
compiled with debugging info which may not exhibit the bug.

The relevant programs are:
    /usr/lib/rpm/find-debuginfo.sh (searches for non-stripped binaries,
separates the debug info)
    /usr/lib/rpm/debugedit (actually does the debuginfo separation, and works
out what source files are used)

[Scott James Remnant (Canonical) (canonical-scott)]

In the Debian world, this would be the job of a tool like debhelper; not dpkg.

[Matt Zimmerman (mdz)]

In fact, debhelper already provides this functionality for Debian packages.

[James Henstridge (jamesh)]

I just looked at the dh_strip program (this seems to be the one in question),
and it only does part of what the RPM "debugedit" program does.

The Fedora debuginfo packages include the sources referenced by the debug
information that aren't usually installed (it puts them in
/usr/src/debug/$SORUCEPACKAGENAME-$VERSION), and also edits the paths in the
debug info so that they can find this source.

Lastly, since it is done automatically it is available for every relevant
package rather than just the ones that have turned on the feature.

[Matt Zimmerman (mdz)]

(In reply to comment #3)
> I just looked at the dh_strip program (this seems to be the one in question),
> and it only does part of what the RPM "debugedit" program does.
>
> The Fedora debuginfo packages include the sources referenced by the debug
> information that aren't usually installed (it puts them in
> /usr/src/debug/$SORUCEPACKAGENAME-$VERSION), and also edits the paths in the
> debug info so that they can find this source.

That's interesting; is there a particular value in repackaging the source,
rather than using the source package for debugging?

> Lastly, since it is done automatically it is available for every relevant
> package rather than just the ones that have turned on the feature.

The reason that we don't do this automatically is not because we can't; it's
because it would double the number of packages in the archive, consume a huge
amount of disk space and mirror bandwidth, etc.

[James Henstridge (jamesh)]

Having the source around means that it is easier to debug problems (you can get
source listings at the crash point, etc).

I guess it would be possible to pull down the source separately, but you'd need
to tell gdb where to find the source code (unless you put the source in the same
place as the package build did). In contrast, with a debuginfo package
everything works out of the box after install (when the user you are trying to
get information from doesn't have much experience, you want to keep the
directions as simple as possible).

Having the paths in the debug info can be useful for software developers too.
Quite often you want full debug information for some of the libraries you use to
help track down bugs in your own code. It means that they don't need to set the
gdb sourcecode search paths each time they want to debug their program.

As far as archives and mirrors go, the Fedora mirrors place the debuginfo
packages in a separate debug/ subdirectory, which makes it easy to perform a
partial mirror that ommits those packages. I guess something similar might work
for a Debian style repository too -- it doesn't matter if the debuginfo packages
aren't mirrored as widely, since they aren't used as much (although when needed,
they are invaluable).

[James Henstridge (jamesh)]

Have been talking with Seb, and we realised that the Fedora *-debuginfo packages
generally seem to be a fraction of the size of the corresponding ubuntu *-dbg
package. For instance, comparing the libgnomeui packages:

             Version Package Size Installed Size
  Fedora: 2.10.0-1 838059 2810k
  Ubuntu: 2.10.0-0ubuntu1 3889082 9104k

The fedora debuginfo package also includes the source code files referenced by
the debugging symbols.

It would be good to work out why the Fedora debug info is so much smaller, since
it might make a full debugging symbol repository more feasible.

[Sebastien Bacher (seb128)]

reassigning to jbailey as discussed

[Sebastien Bacher (seb128)]

http://download.fedora.redhat.com/pub/fedora/linux/core/development/i386/debug/libgnomeui-debuginfo-2.10.0-1.i386.rpm
for the fedora package
apt-get install libgnomeui-0-dbg for the hoary package

[Martin Pitt (pitti)]

Grabbing, since this belongs to my spec: https://wiki.ubuntu.com/AutomatedProblemReports

[Martin Pitt (pitti)]

Testing appreciated:

https://lists.ubuntu.com/archives/ubuntu-devel/2006-July/019196.html

[Martin Pitt (pitti)]

https://lists.ubuntu.com/archives/ubuntu-devel-announce/2006-September/000195.html