Re: Policy or best practices for debug packages?
On Mon, Jul 07, 2008 at 02:41:50PM +0200, Mike Hommey wrote:
> > *) 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.
Yep, that's what everyone else is doing, so that's what I did too with
e2fsprogs.
> > *) 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.
I tried putting them in -dev, and lintian complains with a warning.
So I guess while it isn't official policy yet, it seems to be the
general practice. The e2fsprogs source package just grew an extra 7
binary packages as a result for a total of 20 packages, though. :-)
> > *) 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.
True, although it means there's a bit more work to actually install
the source package, and then running "./debian/rules build" in order
to make sure the sources are unpacked and patches appropriately
applied. With Red Hat all you have to do is unpack the debuginfo
package, and the sources that were used to build the binaries are made
available with no muss and no fuss in
/usr/lib/debug/usr/src/<pkgname>". (And an obvious thing for Red Hat
to have done is to hack gdb to automatically figure out the location
of the source files, possibly by encoding it in the build-id ---
although I don't know if they have done it.0
Is this worth the bloat in packages, especially since the -dbg
packages are architecture specific and thus would be replicated N
times? Probably not, but it's at least worth thinking about the
functionality and deciding whether we want to replicate it.
Speaking of the -g option, does anyone know off-hand whether or not
it's worth it to build with -g3 (to get cpp macro definitions into the
DWARF stubs)?
> 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.
Yep, agreed. That would be nice.
I will say that having started to build and installing the debug debug
packages, for e2fsprogs, being able to run gdb on installed system
binaries is *definitely* very nice. :-)
- Ted
Reply to: