On Tue, 7 Aug 2007 11:55:54 +0200
Loïc Minier <lool@dooz.org> wrote:
> Hi,
>
> On Tue, Aug 07, 2007, Neil Williams wrote:
> > the -dbg (with SONAME)
> [...]
> > provide a binary package
> > librarynamesoversion-dbg
> [...]
> > Josh Triplett <josh@freedesktop.org> on 2007-04-22 19:48
>
> Please don't impose "librarynamesoversion-dbg", a lot of source
> packages do not only provide a library, but also programs, and we
> shouldn't duplicate all packages into having a -dbg (name-dbg).
> This would also imply having multiple -dbg packages when there are two
> libraries in the same source.
(It will be libnameSONAME-dbg, e.g. libqof1-dbg not libraryqof0.7.2-1-dbg)
? 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).
So libqof1 has a -dbg because it installs /usr/lib/libqof.so.1.0.9
gnucash does not need a -dbg (at least not via this policy request)
because it installs loads of libraries in /usr/lib/gnucash/...
The principle here is to make upstream development on Debian easier and
when building gnucash or nautilus from the respective upstream RCS, the
debug code from within that source tree will always be available. What
is needed is to ensure that any other libraries that are part of the
package build dependencies also contain debug symbols so that the
upstream developer always gets a sensible backtrace. It will also make
it easier to get sensible backtraces within Debian bug reports AFTER
the upstream release but that is a useful side-effect rather than my
main incentive.
Private (application) libraries are not affected, only SHARED libraries
(hence the bug title).
"Library source package" == package that only builds a shared library.
e.g. gtk, glib2, qof ...
http://packages.qa.debian.org/g/glib2.0.html
http://packages.qa.debian.org/g/gtk+2.0.html
http://packages.qa.debian.org/q/qof.html
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 believe it should be
encouraged). There is no need for these to be renamed. The intent of
this policy change is to make it easier to debug things like nautilus
by ensuring that not only are the debug symbols available for the
package being inspected (nautilus-dbg) - which one would hope the
person needing the debug symbols would already have installed - but
also the debug symbols for other libraries that are called FROM either
nautilus or the nautilus shared library.
Example:
gpe-expenses. Previous version included all the code in the
application, no debug symbol package (although that could have been
done). The gpe-expenses source only built one binary.
Current version: Upstream split some of the code into a new shared
library and created a public API for that library to be used by other
applications. Debian now has a smaller application, a shared library
with a -dev a -dbg and because the API docs were quite large, a -doc
too.
'Binaries' => [
'libqofexpensesobjects-dev',
'gpe-expenses',
'libqofexpensesobjects-doc',
'libqofexpensesobjects0-dbg',
'libqofexpensesobjects0'
]
The important point is that dependencies OF gpe-expenses and
libqofexpensesobjects also need to have -dbg symbols available. This
includes libqof1, libglib2.0-0 and libgtk+2.0-0 etc. It does not mean
that gpe-contacts or applications using libqofexpensesobjects0 need to
be changed in any way.
Whether the -dbg package should be named after the program or the
library (or whether two -dbg packages might be more useful) is up to
the maintainer.
The point is that the libraries upon which nautilus and
libnautilus-extension1 depend must also provide -dbg symbols -
principally to make it easier to develop and debug nautilus UPSTREAM
using Debian instead of some other distribution but also to make it
easier to get sensible backtraces when nautilus-dbg is actually
installed.
> One example of such a package could be nautilus which has a
> nautilus-dbg with debugging symbols for nautilus and
> libnautilus-extension.
Not affected.
The actual wording for this proposal isn't finalised and it would be
worth ensuring that "library source package" is accurately explained
and defined for these reasons.
>
> I recommend naming the -dbg $source-dbg instead.
Applications can use whatever the maintainer wants for the debug
content. The point is that the library source package foo that (only)
builds libfoo1 and libfoo[1]?-dev must also build libfoo1-dbg. The -dbg
must be the same SONAME as the library whilst the -dev can be either,
depending on how the maintainer wants to handle transitions.
However, qof-dbg would simply be wrong, IMHO. Library source packages
may or may not use the lib prefix to the actual source name but there
is no "qof" package, just libqofSONAME so it would be wrong to provide
a package qof-dbg where only the shared library is built from the qof
upstream source. libqofSONAME-dbg should be mandated for such packages.
This is all about debugging the entire dependency chain from the
perspective of an upstream developer working on a library that depends
on other libraries or an application that depends on third-party
libraries (which includes all GUI applications). The only packages that
need libfooSONAME-dbg are those that only build a shared library and
which do not yet provide debug symbols for that shared library.
Packages that build an application and one or more shared libraries
should also provide debug symbols but the maintainer is free to put
those symbols in whatever package name best suits that package.
> 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
>= or << etc. will not work.
Please read some of the debian-devel thread on this, starting at:
http://lists.debian.org/debian-devel/2007/04/msg00663.html
(Note that the -doc part of the idea is NOT part of this proposal for
policy.)
--
Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/
Attachment:
pgpSUjcw8xn7r.pgp
Description: PGP signature