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
