This is the mail archive of the
mailing list for the elfutils project.
Re: contrasting elfutils debuginfod and clr-debug-info server
- From: Mark Wielaard <mark at klomp dot org>
- To: "Frank Ch. Eigler" <fche at redhat dot com>
- Cc: elfutils-devel at sourceware dot org, arjan at linux dot intel dot com, patrick dot mccarty at intel dot com
- Date: Fri, 7 Feb 2020 10:06:01 +0100
- Subject: Re: contrasting elfutils debuginfod and clr-debug-info server
- References: <20200205173249.GD22246@redhat.com>
On Wed, Feb 05, 2020 at 12:32:49PM -0500, Frank Ch. Eigler wrote:
> Through some comments on phoronix , just became (re?)aware of the
> neat clear-linux debuginfo server facility . It's similar to the
> nixos one we have mentioned before in that it relies on a local fuse
> server expose remote debuginfo artifacts under /usr/src,
> /usr/lib/debug etc. to local tools. The server side relies on a web
> server  that has a carefully unpacked, unified-namespace tree of
> all the artifacts into individual .tar files. This has some
> pros/cons, naturally.
This looks nice. I wonder if we can somehow make debuginfod-client a
backend for a similar Fuse system.
> Some contrasts in a tabular form:
> clear-linux elfutils
> indexed by filename by buildid
> client side sw fuse server apprx. none
> server side sw plain file server debuginfod
> server side disk unpacked, unified-namespace layout orig pkg set
> multi-version maybe, if /usr/src/XXXX filenames unique no problem
When using newer rpm then the filenames should be unique:
But I am not sure how it would handle multiple versions of
> multi-arch req. separate servers no problem
> multi-distro req. separate servers one server ok
One of the use cases of debuginfod is working with local/team builds
for binaries not packaged by a distro. How does clear-linux handle that?