On 2009-08-11, Manoj Srivastava <sriva...@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 -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
