Re: RFS: poco and poco-doc (updated packages) [3rd try]
On Monday 09 June 2008, Russ Allbery wrote:
> George Danchev <danchev@spnet.net> 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
Reply to: