This is the mail archive of the
mailing list for the elfutils project.
Re: Build IDs for finding packages
- From: Mark Wielaard <mjw at redhat dot com>
- To: elfutils-devel at lists dot fedorahosted dot org
- Date: Tue, 29 Jan 2013 09:38:46 +0100
- Subject: Re: Build IDs for finding packages
On Mon, Jan 28, 2013 at 05:11:56PM +0000, Bruce Dawson wrote:
> I'm confused as to how the first install method below (the yum based one)
> is supposed to work. Is the translation from the .build-id path to a
> package name supposed to happen on my machine or on the repository?
In the package database on your machine. It is admittedly a bit of a
hack. It relies on the fact that the debuginfo package that contains
the .debug file with the given build-id also contains that file symlink.
The yum package manager knows that to install a file it needs to check
which package contains that file and install that package. So in practice
it only works for your local (up-to-date) install.
> There is also an additional limitation with this technique which I ran
> into when trying to install old versions of the libc6 symbols on Ubuntu.
> The Ubuntu package manager will not let me install old symbols. It says
> they are incompatible with my currently installed libc6.
yes, and it also only works for the primary arch. Installing debuginfo
for the same package for a 32 and 64 bit binary also wont work.
> The solution I
> came up with is to download the debug packages and extract their contents,
> rather than installing them. Any fully formed solution needs to have this
> option -- a way to download a package based on a build ID without
> necessarily installing it.
yes, this is basically what abrt-action-install-debuginfo does.
> To be clear, the scenario that I am most interested in -- the challenging
> scenario which is not currently addressed and which build IDs could
> address -- is downloading symbols on my machine for a package that is
> installed on someone else's machine. This is necessary when analyzing
> core files or breakpad crashes coming from customers on a wide range of
Yes, this is what build-ids and a universal database were supposed to
solve. Darkserver implements some of that (although not with a full or
universal package database yet). The other part we were imagining was
representing address (for example in backtraces) as module offsets
(or accompany addresses with module load addresses) so all you would
need from a profile/backtrace/etc would be the build-ids and address/offsets
relative to the build-id modules to easily lookup the symbols they
represented. See this old sketch:
Darkserver implements some of this and abrt has some code to do the
address/build-id/offset representation (that way it is also easier to
do stack backtrace deduplication). Now all we need is to make this
really "universal" :)