[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: RFS: ustr



On Tue, Oct 30, 2007 at 10:53:54AM -0400, James Antill wrote:
> Václav Ovsík <vaclav.ovsik@i.cz> writes:
> 
> > Hi,
> > thanks for your suggestions first.
> >
> >> Hi,
> >> 
> >> I am not a DD, so I cannot sponsor etc.
> >> 
> >> I checked your package, it builds in pbuilder, is lintian clean and it
> >> looks good. Some random remarks:
> >> 
> >> * Linda says:
> >> 
> >> $ linda ustr_1.0.1-1_i386.changes
> >> W: libustr-1.0-1; The library libustr is not in a shlibs file.
> >> W: libustr-debug-1.0-1; The library libustr-debug is not in a shlibs file.
> >> E: libustr-debug-1.0-1; Binary /usr/lib/libustr-debug-1.0.so.1.0.1
> >> contains unneeded section comment.
> >> E: libustr-debug-1.0-1; Binary /usr/lib/libustr-debug-1.0.so.1.0.1 is
> >> not stripped.
> >
> > I doubt about worthiness to have `-debug' packages now. Should I exclude
> > libustr-debug-1.0-1 and libustr-debug-dev? If someone needs to debug
> > ustr, he can build a debug library himself and so have the sources...
> 
>  The debug library is more about debugging the applications that use
> ustr than the library itself. Some of this is mitigated with malloc
> check and USTR1_CHK etc. in 1.0.2, but the debugging library can still
> catch a lot of errors that the normal library can't.
> 
>  The way I have it setup in Fedora, it's almost a second library so
> the libustr package isn't affected (with extra deps. etc.) by the
> libustr-debug package existing or not.

My intention was similar, first version of ustr source package builds
into:

libustr-1.0-1 - Micro string library: shared library
libustr-1.0-1-dbg - Micro string library: debugging symbols
libustr-dev - Micro string library: development stuff
libustr-doc - Micro string library: documentation

libustr-debug-1.0-1 - Micro string library: shared library for debugging
libustr-debug-dev - Micro string library: development stuff for debugging

Last two packages contain debug flavour of ustr. I instructed CDBS to
not strip this library, because I thought, that this library is used
only for developer to test your application and debug it. I expected,
that this flavour of lib is not for production and that no package
should depend on it or use it. Lintian checker didn't report any problem
there and I didn't run linda on result.

There is possibility to fulfill Debian policy or habit by separating
symbols into a bit strange looking package libustr-debug-1.0-1-dbg :-).
So I can end with branch of packages

libustr-debug-1.0-1
libustr-debug-1.0-1-dbg
libustr-debug-dev

Maybe another approach can be to separate debugging symbols into
separate file and include this into libustr-debug-1.0-1. This solution
can be only workaround for the linda error report and makes a sence only if
the debug library have not a sense without debugging symbols.

It seems to me (Makefile), that debug flavour of static library at least
must by build if I want to run library checks (make check),
so time & resources can't be saved by excluding debug flavour.

Q1: Is sufficient libustr-debug.a alone for debugging? That is
libustr-debug-dev package remaining only and no shared version.

If Q1 reply is no:

Q2: Has libustr-debug-1.0.so.1.0.1 a sense without debugging symbols?
That is assertions and reports by library are in most cases worth even
without further inspection using gdb that can to step into library.

Excuse my naive questions please, this is my first Debian package.

Regards
-- 
Zito



Reply to: