On Tue, Aug 11 2009, Sune Vuorela wrote: > On 2009-08-10, Manoj Srivastava <sriva...@debian.org> wrote: >> On Mon, Aug 10 2009, Sune Vuorela wrote: >> >>> On 2009-08-10, Manoj Srivastava <sriva...@debian.org> wrote: >>>> I would also add that the debug symbols should live in >>>> "/usr/lib/debug/" . /full/path/to/lib_or_binary, blessing the current >>>> practice. >>> >>> You are missing the new features of build-id as written earlier by >>> insisting on this.
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? * 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 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. manoj -- An apology for the devil: it must be remembered that we have heard only one side of the case. God has written all the books. Manoj Srivastava <sriva...@debian.org> <http://www.debian.org/~srivasta/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org