Re: 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
Reply to: