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

Status on (experimental) ddeb support in Debian

Here is an updated status on ddeb support in Debian.

The big picture: Still not done.  Currently we are just waiting for two
parties to implement the missing parts.

Where are we?

 * We seem to have a rough consensus on using the ".deb" extension for
   ddebs.  I have implemented this in experimental.

 * dpkg-dev now permits "out of band" .debs (in 1.18.0).  I have
   already tested it and it works for ddebs.

 * debhelper have the necessary patches in experimental to produce
   policy compliant ddebs with the ".deb" extension.  Except a minor
   detail (see "What is missing?" below), debhelper implements all the
   necessary parts for ddebs.
   - This includes a method for migrating from a manual -dbg to ddebs.
     (see "Recent changes to debhelper/ddebs")

 * lintian/2.5.31 (in testing) is almost as ready as it can be for
   ddebs with the ".deb" extension.

What is missing?

 * Support in dak to:
   - (possibly) accept out of band binaries.
   - skip NEW processing for "new" ddebs.  If only to avoid overloading
     the FTP-masters.
   - move it into a separate component to avoid a huge increase in the
     size in the Packages files on the mirrors.

 * Then debhelper needs:
   - to remove/revert a patch to make ddebs conditional based on
   - a change to a new section instead of the existing "debug" section.
     (I thought I had implemented that already - but unfortunately, I
      had not)
   - an upload to unstable.

 * Lintian will need some minor changes to accept the new section.

Recent changes to debhelper/ddebs

  * DH produces policy compliant .debs (using usr-share-doc symlinks).
  * DH produces ddebs that multi-arch:same only when the original binary
    is.  Otherwise, they will be "multi-arch:no" (by omitting the
    multi-arch field).
  * DH /no longer/ uses "pkg:arch" dependencies.  They are not very
    useful as APT and dpkg (among others) do not agree on "what that
    dependency means".
  * DH supports a -dbg => ".deb ddeb" migration.  See the
    --ddeb-migration option in dh_strip (should replace the
    --dbg-package option)
  * DH inhibits ddeb creation when either "dh_strip -k", "dh_strip
    --dbg-package" is used or when either "noddebs" or "nostrip" are
    given as/in DEB_BUILD_OPTIONS.


I have been asked a few times about some of the following, so I figured
other people might be interested in these:

 Q: Will there be one ddeb per source or per binary package?
 A: One per binary which are:
    - architecture dependent
    - contains at least one object file that support attachable debug
      symbols and were compiled with "build-id".

 Q: Will objects *without* build-ids be supported?
 A: Support is not planned.  Technically, it is feasible but it would
    immediately prohibits "multi-arch:same" support.  To my knowledge,
    "linux" (and possibly other kernels) are the only consumer that
    does /not/ support build-id based debug symbols.

 Q: What is the consequence of not using "pkg:arch" dependencies?
 A: See the next section

 Q: What is the consequence of (/not/) using the "debug" section for
    ddebs? / Why did you (want to) use a new "debugsym" section for
 A: The use of the "debugsym" section was mostly intended as an reliable
    way to discriminate automatically generated ddebs from manual -dbg
    packages (without relying on the file name).  There is otherwise no
    technical requirement for choosing one over the other.

 Q: What debhelper tools at involved in ddebs?
 A: Currently, dh_strip, dh_md5sums, dh_gencontrol and dh_builddeb.
    Note that dh_gencontrol (via dpkg-gencontrol) declares that the
    ddeb will be built, so dh_gencontrol must be used together with

 Q: Any known breakages so far caused by ddebs?
 A: The reproducibility team has reported one FTBFS (#784211) and one
    FTBRFS (#785731) so far, which were not (known to be) caused by
    bugs in the ddebs implementation itself.

Consequences of the absence of "pkg:arch" dependencies

All scenarios brought up so far leads only to a minor "degradation" in
usability.  In summary my conclusions on this topic are:

 * The issue *only* affects ddebs for "Multi-Arch: foreign" packages.

 * It permits APT and dpkg to install the ddeb for the wrong
   architecture.  This is a "silent failure in /not/ providing useful
   debug symbols".

 * I have considered it "insignificant" relatively to disabling ddebs
   for "Multi-Arch: foreign" binaries, which is the other major
   alternative to "solving" this[1].

The exciting part of this is that "pkg:arch" dependencies are currently
doomed to fail, since APT and dpkg do not agree on what exactly
satisfies "pkg:arch".


[1] I am sure someone can think up a solution involving architecture
specific package names.  However, I would be surprised if such a
solution was in fact simple, truly reliable and widely welcome.

Attachment: signature.asc
Description: OpenPGP digital signature

Reply to: