On 2021-12-19, Nate Graham <n...@kde.org> wrote: > For what it's worth, I don't think server-wise retracing is solely a > workaround for distro-specific issues. Even for distros that ship debug > symbols, I often find in my bug triaging that it can be a challenge to > get users to actually use them.
Server side retracing is king of orthogonal to this. Server side retracing is taking the coredump (maybe minidump), shipping it to a server and combining it with debuginfo from the original binary build. But this would require the serverside retracer to be able to consume debuginfo packages correctly for all (relevant?) distros and all historic? versions. The thing drkonqi does is it tries to do client side retracing and tries to get the package manager to get the correct debuginfo packages available. From a package manager perspective[*], that's often quite hard to get right, and thus why it often does not give that good bug reports. With debuginfod integration and distributions providing debuginfod, this can become better. But for both of them, it needs debuginfo available from somewhere. If the distro don't provide those, then we, no matter what, are out of luck. /Sune [*] Imagine user installs dolphin 5.4.3-1, experiences a crash 2 weeks later, drkonqi tries to get package manager to install debug symbols, but 5.4.4 has since come out. Unless the package manager systems keeps debuginfo around much longer than the package it belongs to (which I haven't heard anyone actually do), then this will not match.