On Monday 09 June 2008, Russ Allbery wrote: > George Danchev <[EMAIL PROTECTED]> writes: > > Actually it would be smarter do ship only the detached debugging symbols > > I believe. I can't think of a use case where the debugging version of > > the shared library would be desperately needed or preferred, or I'm > > wrong ? > > Well, usually the reason why a shared library builds a separate debugging > version is that the code actually changes. In other words, rather than > just having debugging symbols, the functions in the library actually work > differently. Perhaps more checking is done, or more logging, or the like. > > If that isn't the case here and the only difference is that one has > debugging symbols and the other doesn't, then I agree, you should just > ship the detached debugging symbols for the regular library and ignore > (and not package) the d version.
Ah sure, that makes sense to me. Thanks. > > Nod. By the way I was looking at the lintian-1.24.0/checks/binaries: > > around row 148; shouldn't expected_name as of name.so.[0-9] also be > > taken into account ? > > I can't figure out what you're getting at. Line 148 is: > > $expected_name =~ s/\.so(\.|\z)//; > > which is one part of the code that mangles a library SONAME into a package > name. This line removes the ".so." part of the SONAME. > Ops, sorry bad row counting. I meant that $expected_name =~ s/([0-9])\.so\./$1-/; won't cope with well with name.so.1 -- pub 4096R/0E4BD0AB 2003-03-18 <people.fccf.net/danchev/key pgp.mit.edu> fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
