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[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".
Thanks,
~Niels
[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.
signature.asc
Description: OpenPGP digital signature
