Differences between revisions 15 and 16
Revision 15 as of 2015-04-03 21:44:25
Size: 4895
Editor: NielsThykier
Comment: Add remark about dpkg-genchanges warnings
Revision 16 as of 2015-04-11 07:22:34
Size: 4889
Editor: NielsThykier
Comment: Reduce the "$package:$arch" dependency to a "$package" dependency - APT does not support the former and it is not needed
Deletions are marked like this. Additions are marked like this.
Line 59: Line 59:
   * Dependency on ``$package:$arch (= $version)``    * Dependency on ``$package (= $version)``

Summary

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.

Status

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

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

Why

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

Fedora

StackTraces Packaging:Debuginfo

Ubuntu

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.

Proposal

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.

Implementation

debhelper

  • dh_strip:
    • without --dbg-package: Saves extracted debugging info in debian/$package/usr/lib/debug. Leaves a marker
    • with --dbg-package: No change
  • dh_builddeb for packages marked to have extraced debug info:
    • Ignore /usr/lib/debug for package
    • Creates additional ddeb with this characteristics:
      • Only short description, mirrored from the main package
      • Dependency on $package (= $version)

      • /usr/lib/debug
      • /usr/share/doc/$ddeb/copyright
        • Omit?
        • Use --link-doc? Given the very strict dependency and that they are same architecture, --link-doc should be safe here.
  • Prototype available at https://anonscm.debian.org/git/users/nthykier/debhelper.git, branch super-cow-ddebs-support

    • Use "export DH_BUILD_DDEBS=1 dpkg-buildpackage" to enable it
    • dpkg-genchanges will emit some warnings (similar to the ones in #781074)

dak

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/.

britney

lintian

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

Questions

  • 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?