FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 07-07-2008, 12:08 PM
"Theodore Ts'o"
 
Default Policy or best practices for debug packages?

There doesn't seem to be anything in policy about debug packages, are
there any wiki pages or best practices documents about what are the best
ways to create debug packages?

Some of the questions I have are:

*) I assume that the priority of -dbg packages is extra

*) What section should -dbg packages be placed into? Should it be the
section that the parent package is in, or something like "devel"?

*) Do we dump everything into /usr/lib/debug, i.e.,
/usr/lib/debug/sbin/e2fsck? Or should we put it in
/usr/lib/debug/<pkg>, i.e., /usr/lib/debug/e2fsprogs/sbin/e2fsck?
Most packages I've seen seem to be doing the former.

*) Is it OK to include the -dbg information in a library's -dev package?
Or should it be separated out? Otherwise as more and more packages
start creating -dbg packages, the number of packages we have in the
debian archive could grow significantly.

*) Red Hat includes source files in their debuginfo files, which means
that their support people can take a core file and get instant feedback
as to the line in the source where the crash happened. But that also
means that their debuginfo packages are so huge they don't get included
on any DVD's, but have to be downloaded from somebody's home directory
at redhat.com. (which appears not to be published, but which is very
easy to google for. :-) What do we want to do?

There are probably more questions like this, but in case all of this has
been decided and I just missed it while google searching for the
relevant policy/best practice document, I'll stop now. :-)

- Ted




--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 07-07-2008, 12:41 PM
Mike Hommey
 
Default Policy or best practices for debug packages?

On Mon, Jul 07, 2008 at 08:08:39AM -0400, Theodore Ts'o <tytso@MIT.EDU> wrote:
>
> There doesn't seem to be anything in policy about debug packages, are
> there any wiki pages or best practices documents about what are the best
> ways to create debug packages?
>
> Some of the questions I have are:
>
> *) I assume that the priority of -dbg packages is extra
>
> *) What section should -dbg packages be placed into? Should it be the
> section that the parent package is in, or something like "devel"?
>
> *) Do we dump everything into /usr/lib/debug, i.e.,
> /usr/lib/debug/sbin/e2fsck? Or should we put it in
> /usr/lib/debug/<pkg>, i.e., /usr/lib/debug/e2fsprogs/sbin/e2fsck?
> Most packages I've seen seem to be doing the former.

/usr/lib/debug/$pathoforiginalfile

This is where gdb is going to look for these debug info.

> *) Is it OK to include the -dbg information in a library's -dev package?
> Or should it be separated out? Otherwise as more and more packages
> start creating -dbg packages, the number of packages we have in the
> debian archive could grow significantly.

I think the problem is going to be with size way before becoming a problem
with the number of packages.

> *) Red Hat includes source files in their debuginfo files, which means
> that their support people can take a core file and get instant feedback
> as to the line in the source where the crash happened. But that also
> means that their debuginfo packages are so huge they don't get included
> on any DVD's, but have to be downloaded from somebody's home directory
> at redhat.com. (which appears not to be published, but which is very
> easy to google for. :-) What do we want to do?

You don't need source files in the debuginfo files to get line numbers.
You only need line tracking information, and if you build with -g, that is
already what you get.

The only package that is deliberately built without line info that I know of
is the glibc.

> There are probably more questions like this, but in case all of this has
> been decided and I just missed it while google searching for the
> relevant policy/best practice document, I'll stop now. :-)

Note that it would be better for our users if we could have a debug info
server instead of having them install dbg packages, it could be nicer.
Obviously, gdb would need to be able to talk to it.

But until then, it might also be easier if the dbg packages could be easily
installed without root access. A wrapper script that sets up a temporary
cache area for apt-get and dpkg so that the deb could be downloaded and
installed at a user writable place, and wraps gdb so that it gets files
from this place instead of /usr/lib/debug, would probably be very helpful.

Mike


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 07-07-2008, 12:59 PM
Neil Williams
 
Default Policy or best practices for debug packages?

On Mon, 2008-07-07 at 08:08 -0400, Theodore Ts'o wrote:
> There doesn't seem to be anything in policy about debug packages, are
> there any wiki pages or best practices documents about what are the best
> ways to create debug packages?

There was some discussion around #436419, seeking to add some Policy in
this area:

http://lists.debian.org/debian-devel/2007/04/msg00663.html

http://lists.debian.org/debian-devel/2007/04/msg00692.html

> Some of the questions I have are:
>
> *) I assume that the priority of -dbg packages is extra

As advised by lintian and enacted by ftp-masters.

>
> *) What section should -dbg packages be placed into? Should it be the
> section that the parent package is in, or something like "devel"?

Library -dbg packages will almost inevitably end up in lib. Personally,
I think that's right.

>
> *) Do we dump everything into /usr/lib/debug, i.e.,
> /usr/lib/debug/sbin/e2fsck? Or should we put it in
> /usr/lib/debug/<pkg>, i.e., /usr/lib/debug/e2fsprogs/sbin/e2fsck?
> Most packages I've seen seem to be doing the former.

/usr/lib/debug/usr/lib/libqof.so.2.0.0

I don't see why a package directory would be useful there but the real
question is:

*) The current usage is /usr/lib/debug/ - if we change that, would the
tools using -dbg packages be able to find the symbols?

>
> *) Is it OK to include the -dbg information in a library's -dev package?
> Or should it be separated out? Otherwise as more and more packages
> start creating -dbg packages, the number of packages we have in the
> debian archive could grow significantly.

This was covered in the original discussion - a separate section of the
archive is a better solution. Not everyone who needs the -dev needs the
-dbg - e.g. the autobuilders do *not* need -dbg symbols for
build-dependencies.

>
> *) Red Hat includes source files in their debuginfo files, which means
> that their support people can take a core file and get instant feedback
> as to the line in the source where the crash happened. But that also
> means that their debuginfo packages are so huge they don't get included
> on any DVD's, but have to be downloaded from somebody's home directory
> at redhat.com. (which appears not to be published, but which is very
> easy to google for. :-) What do we want to do?

Combine apt-get install foo-dbg with apt-get source foo ? Isn't it up to
the debugging tool to correlate one with the other, rather than the
distro?


--


Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/
 

Thread Tools




All times are GMT. The time now is 04:26 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org