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 DH_BUILD_DDEBS - 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. FAQ === 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 ddebs? 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 dh_builddeb. 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. 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". Thanks, ~Niels  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.
Description: OpenPGP digital signature