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?
--
vda