Bug#436419: Mandatory -dbg packages for shared libraries

[Loïc Minier <lool@dooz.org>]

On Tue, Aug 07, 2007, Neil Williams wrote:
> ? This change only affects shared libraries - i.e. library source
> packages installing shared libraries in /usr/lib/ and with a -dev, not
> private libraries installed in /usr/lib/package/ and not application
> source packages that also contain shared libraries. (Although -dbg
> content should be encouraged separately).

 Yes, this I understood, I took the example of a source package which
 produces a shared library AND binaries.

> The principle here is to make upstream development on Debian easier

 While I understand your concern, *requiring* the -dbg package to be
 named libname<soname>-dbg is a problem for sources which want to offer
 debugging binaries for the binary applications which have some binaries
 (e.g. /usr/bin/nautilus ends up in the nautilus package and is built
 along /usr/lib/libnautilus-extension.so.1 which ends up in
 libnautilus-extension1 and I want to provide debug symbols for BOTH in
 the nautilus-dbg package).

 To be clear, the only part I'm not confortable about is forcing the dbg
 name to start with the name of the shared library package as it might
 not make sense in the nautilus case or when a source builds multiple
 shared library packages (having two -dbg for two indepent libraries
 built from the same source would bloat the archive needlessly).

 I join Mike's feeling that we would be best served by a ddeb
 infrastructure.

> "Library source package" == package that only builds a shared library.
> e.g. gtk, glib2, qof ...

 gtk+2.0 also builds libgtk2.0-bin which ships gtk-query-immodules-2.0;
 you can find debug symbols for gtk-query-immodules-2.0 in
 libgtk2.0-0-dbg (the "libgtk2.0-0-dbg" name is for historical reason, I
 would name it gtk+2.0-dbg or similar nowadays, but gtk+2.0 wont ever
 change SONAME anyway).  glib2.0 also builds /usr/bin/gobject-query (in
 libglib2.0-dev) which has debug symbols in the -dbg.  etc.

> http://packages.qa.debian.org/g/glib2.0.html
> http://packages.qa.debian.org/g/gtk+2.0.html

 (Thanks, I maintain these ;-)

> Source packages that provide an application and a *shared* library (i.e.
> one with a -dev package) can provide a -dbg to complement the -dev but
> that isn't expressly part of this proposal.

 I do think one source package should aim at providing only one -dbg
 package when possible.

> >  We don't really need to keep -dbg for the transitional period where two
> >  SONAMEs of the same lib from the same source are on user systems and we
> >  can have very lax dependencies in the -dbg packages and on the -dbg
> >  packages.
> ? To debug libfoo1 you must have libfoo1-dbg, libfoo0-dbg won't work.
> The dependency needs to be fixed as:
> Depends: ${binary:Version}
> i.e. libfoo1-dbg 1.2.3-4 depends on libfoo1 1.2.3-4

 But if libfoo1 is around, then libfoo0 is already in the process of
 going away (if you mean a SONAME change in a source); if you build two
 SONAME from two sources, or two SONAME from the same source, you can
 still ship the -dbg of each build in one -dbg per source, there's no
 technical issue.  On the other hand, renaming the -dbg to carry the
 SONAME is gratuitous and doesn't have any additional value.

-- 
Loïc Minier