Differences between revisions 9 and 10
Revision 9 as of 2013-11-27 01:50:12
Size: 4267
Editor: ?OllyBetts
Comment: typo
Revision 10 as of 2013-12-23 01:19:10
Size: 4357
Editor: PaulWise
Comment: lintian warnings to cleanup -dbg packages.
Deletions are marked like this. Additions are marked like this.
Line 68: Line 68:
== lintian ==

Warn about -dbg packages that are duplicates of the -dbgsym packages.


The proposal is to automatically produce debugging symbols for everything in the archive, without the developers needing to add -dbg packages everywhere, which are rarely used and right now we mirror everywhere.


Original proposal created by: ?EmilioPozueloMonfort; his version is at AutomaticDebugPackages/OldProposal

New proposal created by: SamuelBronson (please feel free to edit, though!)


Original "Why"

This thread in debian-devel expresses the need of this change. The reasons mentioned there include:

  • -dbg packages are mirrored everywhere, which is a waste of mirror space and bandwidth since they are rarely needed.
  • It would be possible to integrate bug-reporting tools to get meaningful stack traces.
  • Adding -dbg packages by hand everywhere is a waste of time and resources.

We don't want to completely remove them without having a replacement though. They are very useful when the time arises. The proposed replacement is to automatically build .ddeb packages that contain those debug symbols, and that are moved to a separate component/archive that isn't mirrored. That way we get debugging symbols for every binary in the archive with no effort, and solve the mirror problems.

Existing Practice


StackTraces Packaging:Debuginfo


Ubuntu has already done this.

See their spec and the package they use to generate ddebs.

TL;DR: they divert dh_strip to generate -dbgsym packages with filenames ending in .ddeb, and set up their archive manager to keep those somewhere out-of-the-way. One thing that's changed since they wrote the spec is the handling of packages that already ship symbols in -dbg binary packages: instead of making -dbgsym packages that conflicts with & breaks the -dbg packages, it now makes the -dbgsym packages into metapackages that pull in the relevant -dbg packages.


As Ubuntu's scheme seems good, we should just copy it, except presumably without the diversion of dh_strip.

It seems like all we really need to do here is:

  1. Prepare dak to accept ddebs and file them appropriately. (Maybe britney too?)
  2. Modify dh_strip to do what Ubuntu's pkg-create-dbgsym would make it do. (In theory we could just use pkg-create-dbgsym, but we won't because it diverts dh_strip, which obfuscates things and prevents others (like users) from diverting it.)
  3. Fix any packages that somehow take exception to the unexpected debuginfo packages.
  4. [at leisure] Drop -dbg packages, or if they contain something besides separate debug info, drop the separate debug info and rename the packages.


debhelper (dh_strip)

  • dh_strip creates $package-dbgsym for each package it handles that includes something it can strip.

  • If called with --dbg-package it just creates a dependency to the named package.

  • Each ddeb depends on $package:$arch (= $version).


ddeb can be installed into the same archive then the other packages and everything else should still work. They would be excluded on a per-mirror basis.

  • ddeb will have no override entries, so no priority or section.
  • They may not show up in the control-file, nor have a long description.
  • dak will accept $binary-dbgsym_$version_$arch.ddeb if a $binary_$version_$arch.{deb,udeb} is included in the same upload.

  • ddeb will go into the component "debug", so will show up in ./pool/debug/ (The pool-prefix is pretty much hardcoded, so making it variable would need a lot of work). No other packages will be allowed in "debug".

  • Standalone Release/Packages in ./debug/dists/.



Warn about -dbg packages that are duplicates of the -dbgsym packages.


  • It looks wrong to call dpkg-deb from dh_strip. Is there a way to avoid this?

  • How to generate recommends for the library dependencies?
  • Do we need the dependency from ddeb to deb?
  • Do we need to split ddeb per main/contrib/non-free?