This time I am not going to blog about KCall, but about DrKonqi. Dario Andres and I, the drkonqi maintainers, are thinking of adding some new features for KDE 4.4. As you already know, most distros out there ship stripped binary packages with their debug symbols put in separate packages. One of the features that we want to add in drkonqi for KDE 4.4 is to make it able to install the required debug packages when there are missing symbols in a crash report.

Our first idea for implementing this was to have a shell script installed somewhere, which by default will do nothing, and let distributions customize it to install the required packages. The input given to the script is the executable name and all the libraries that appear in the backtrace with missing debug symbols. For example, a backtrace line that reads like “#5 0xbf123456 in ?? from /usr/lib/libkdecore.so.5″ probably means that the library “/usr/lib/libkdecore.so.5″ is missing debug symbols, so that library path is passed as an argument to the script.

This is already implemented in trunk (it was very easy to do), but I now want to go further than that. Being a debian packager myself, I attempted to write an utility to do this for debian. I found an easy algorithm that takes as input all the filenames of the binaries that need debug symbols and outputs the names of the packages that need to be installed, using apt-file as a backend for searching package contents. While working on this, I came up with the idea to put this algorithm in a KJob, which eventually made me think of another possible implementation of this feature: Have a unified GUI in drkonqi that takes plugins; every distro will have its own plugin and each plugin will export a KJob that will do all the work (finding and installing packages), or alternatively, that KJob will only find the packages that need to be installed and then drkonqi will use packagekit to install them or display some message to tell the user what to install if packagekit is not available (which is the case for debian, btw).

This scenario would be better than the scenario with the script, because it will allow us to have a unified GUI in all distributions and will also reduce the work of the distributors, as they will have to write only one small plugin instead of a whole application to do all the work. I don’t know however if this scenario works for other distributions, as I don’t know how they handle debug packages.

So, dear fellow packagers and anybody else who has an opinion on this, I would like to know how your distribution handles debug packages and what is your opinion on all this, so that I can decide what to do and how to do it. :)