[Bugsquad] Debug packages in Shaman

[George Kiagiadakis]

Hi,
First of all, sorry for not replying immediately, I was a bit busy
with my family reunion for the Christmas :)
Secondly, thanks for taking care about this feature :)

Let's get to the subject now...

2009/12/27 Darío Andrés <andresbajotierra at gmail.com>:
> 2009/12/25 Dario Freddi <drf54321 at gmail.com>:
>> In a possible future where the bug reporting tool would act as a very basic
>> frontend to libshaman letting people install debug packages, I wanted to know
>> what features would you guys like/need to have in order to make such a thing
>> possible. For now you're just able to get the list of packages containing the
>> debug symbols (of course from a package you're able to find out if it's
>> installed, etc). Should you need some more stuff, it's your chance to ask :)
>>
>
> I will briefly explain how we get debug symbols packages installed:
>
> - From the incomplete backtrace, we get the path of the .so libraries
> with missing debug information.
> (ex. "/usr/lib64/libQtCore.so.4")
> - Using that path we get which packaged installed it
> (ex. "libqt4")
> - Now we check which package contains the debug symbols of the
> previously fetched packagename
> (ex. "libqt4-debuginfo" contains the debuginformation for "libqt4")
> - Those packages get installed
> - The backtrace is regenerated. (and hopefully complete now :) )

That's not quite the procedure we follow. Let me explain it in more detail.

Let's see this from DrKonqi's point of view. DrKonqi only has the
information given from gdb. gdb can tell which binaries are missing
debug symbols (from the backtrace), but it could also give other
information in the future, such as build-ids (see below)...

When I designed this, the abstraction I chose to follow is this:
Step 1) Get names (with paths) of the binaries that lack debug symbols
using the backtrace as the source.
Step 2) Pass them as arguments to the distro-specific backend which
will hopefully install their debug symbols.
The distro backend currently is a shell script that distributions
should provide. DrKonqi doesn't do anything more than that. The distro
backend can use any way that it likes to get those symbols.

I chose this abstraction because I found that it can work in the
distributions that I had a look at. As a proof of concept, I
implemented 3 distro backends (which can be found in
kdebase/runtime/drkonqi/doc/examples), which I'll try to explain how
they work:

1) The debian backend
Debian currently doesn't have any native package manager support for
debug symbols packages, although it is planned to add support in the
near future. The sure thing about debian (and at least debian kde
packages) is that given a binary with its absolute path (ex.
/usr/bin/kwrite), its debug symbols are in /usr/lib/debug/$BINARY (ex.
/usr/lib/debug/usr/bin/kwrite). So, the backend just uses apt-file to
look for the package that contains this file (the /usr/lib/debug/...
one) and then it installs it. This is sub-optimal, since apt-file
takes a lot of time to search and it also needs to update its database
from the internet, but it will hopefully be improved when apt has
native support for finding debug packages.

2) The opensuse backend
Opensuse's package manager (zypper) has native support for this
feature, using build-ids. Each binary has a build-id embedded in its
.note section (iirc) and there is a tool to tell you the build id of
any given binary. Then zypper can automatically install the debug
symbols given the build-id (using "zypper install -C
debuginfo(build-id)=$buildid"). This is very fast and very reliable,
since the build-ids are unique, given to the binary at build time
using some hash function and they are stored in the packages database
as if they were packages, so that the package manager can install them
very easily. (Note: Debian is also going to use a similar system with
build-ids in the near future.)

3) The fedora backend
Fedora supports the scenario that Dario Andres described. First you
retrieve from the rpm database the package that provides the given
binary, then you use their custom "debuginfo-install" program which
takes a package name as an argument and it installs its debug symbols.

As you can see, in all 3 backends, the input is just the absolute
paths of the binaries that are missing debug symbols, and this seems
to work nicely for all 3 distributions. So, if you think shaman could
provide the same interface, then I think it would be the best, to
allow drkonqi to have a shaman backend using the same interface that
it uses for the other backends and let distros choose whether they
want to use the shaman backend or their own.


Best regards,
George