Re: Automatic Debug Packages
On 2009-08-11, Manoj Srivastava <srivasta@debian.org> wrote:
> Hmm. I see very little benefit here. Firstly, to use build id,
> you have to intercept the upstream build system and add --build-id
> (and perhaps the --build-id-style) option to ld, instead of the current
> method of letting the upstream build happen and working on the produced
> objects -- this is more intrusive. And what do we gain?
The plan is to make --build-id the default (As it is on many other
distributions).
>
> * For the "build ID" method, GDB looks in the `.build-id'
> subdirectory of the global debug directory for a file named
> `NN/NNNNNNNN.debug', where NN are the first 2 hex characters of
> the build ID bit string, and NNNNNNNN are the rest of the bit
> string. (Real build ID strings are 32 or more hex characters, not
> 10.)
>
> So, we would still need to create "/usr/lib/debug/"
> . /full/path/to/lib_or_binary/ in either case, and instead of the
no. it would be /usr/lib/debug/.build-id/NN/NNNNNN.debug
> lib-or-exec name, create NN/NNNNNNNN.debug file there (which is non
> human readable, really). What have we gained? There is no potential for
> file name conflicts, since if there are file name conflicts in the
> debug symbol files, there would be file name conflicts in the
> corresponding packages, which is already a bug in Debian.
>
> I see added complexity with no real benefit for us: it might
> have value in an environment where file conflicts are not verboten.
And the next step is to provide /usr/lib/debug/.build-id exported from
some internet service so that you download debugging symbols on demand,
for example thru drkonqi or bug-buddy or maybe directly with gdb.
Having a reliable way of getting from a random library version and
random executable version to get the exact corresponding debug symbols,
the build-id method is just much more reliable.
/Sune
Reply to: