Hi Richard, folks,
Jiri said to me on IRC:
<jmoskovc> the debuginfo-install support in PackageKit seems to be finally working <jmoskovc> so if you want, you can change the old debuginfo-install script for pk-debuginfo-install
Here is a quick recap how we currently do it, what's wrong with it, and how it can be improved.
When we process a crash, we have a core file. We just run gdb on it in batch mode by running
gdb -batch -x FILE
where FILE contains:
file BINARY code COREFILE thread apply all backtrace full q
This produces a backtrace. gdb tries to produce better backtrace (with line numbers, variable names and so on) using debug info.
It tries to locate debuginfo by finding executable's build id, and uses debuginfo if it is found.
example: # ls -l /usr/lib/debug/.build-id/00/5af5b5e7d6ab560825b0747fcbe41112431b8c.debug lrwxrwxrwx 1 root root 28 2009-07-20 18:08 /usr/lib/debug/.build-id/00/5af5b5e7d6ab560825b0747fcbe41112431b8c.debug -> ../../usr/bin/makestrs.debug
However, we (abrt) do not know whether debuginfo is installed, so currently we just run "debuginfo-install -y -- PACKAGE".
This is a simple approach, but it has several drawbacks.
* we install debuginfo packages even if debuginfo files are present. For example, some people in large installations mount a network filesystem on /usr/lib/debug/ with *all* debuginfos installed, in order to reduce unneeded downloads. Running debuginfo-install in this case is not only unproductive, it will likely fail.
* we install all debuginfos, even those not needed for this particular crash. There may be dozens of libraries linked in, yet the stacktrace processing may not need debuginfo for most of them.
* Jiri pointed out another problem: we may be installing debuginfos for a wrong version of the executable. It does not mess up stacktrace, it just does not help gdb at all.
So, Richard, what is this pk-debuginfo-install thing, and how it can help us here? In what ways is it different from debuginfo-install?