[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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


Reply to: