Hi Daniel,
On Wed, 2021-10-27 at 10:01 +0100, Daniel P. Berrangé wrote:
Getting RPM NEVRs directly from the coredumps is something that
will be incredibly helpful for people dealing with support
requests after crashes. build-ids have always been very tedious
to deal with and as you say RPM database may be newer than what
is in memory. This benefit alone will make it all worthwhile
from my POV.
[...]
Furthermore as someone dealing with bug reports I don't have access
to the RPM database. That is on the end user's machine. Often all I
get is a core dump attached to a bug report, and if I'm lucky they
manually typed a couple of RPM NEVRs into the bug description. On
many occassions I've found the NEVRs the user supplied in the
description to be wrong due to mistakes on the bug reporter's side
collecting the data.
Note that we have been working on integrating debuginfod in more
distros (it will be enable by default in Fedora 35):
https://debuginfod.fedoraproject.org/
There is also an "global" debuginfod server that aggregates all other
distros debuginfod servers:
https://debuginfod.elfutils.org/
Which should delegate to the fedora, opensuse, debian, altlinux, etc.
debuginfod servers to query their build-id databases.
Which means it should be a lot easier to get, given a build-id (in a
core file, or simply in memory even if the original ELF file on disk is
gone) the executable, debuginfo and associated source files.
For the next version of debuginfod we are trying to also give you
information about the original archive (including the nevr in the name)
that the information came from.
This is not to say we don't need the Package information in ELF files.
Having that (especially if it includes the corresponding debuginfod
URL) will make it even easier to get the corresponding debuginfo and
sources for a given ELF binary/build-id.
Cheers,
Mark