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
