On Sun, 20 Dec 2015 at 08:53:16 +0000, Niels Thykier wrote:
> In the actual implementation we got live now, there are a couple of
> changes though.
>
> * The dbgsym packages use the .deb extension
For the non-Debian projects for which I developed this patch, we still
need at least basic support for .ddeb files, because Ubuntu's toolchain
still produces those (and as far as I can tell it will continue to do
so indefinitely - they no longer use pkg-create-dbgsym, but they have a
patch in their dh_strip to make it produce .ddeb instead of .deb files).
I wouldn't object to simplifying it by treating .ddeb files as exactly
equivalent to .deb, so they go alongside ordinary debs, instead of
creating a <component>/debug pseudo-component? That's what happens right
now when you import a Debian-built -dbgsym package into an unpatched
reprepro. (You can't currently import an Ubuntu-built -dbgsym package
at all.)
(Cc'ing my colleague Lucas Kanashiro who will be looking into rebasing
this patch for our own use - we need a fork of reprepro that supports
this, even if it can't go upstream, so we might as well provide an
updated patch on this bug too.)
> In DAK / the Debian infrastructure, the dbgsym packages are placed in a
> separate component called "<suite>-debug".
Isn't that a suite or a "dist" or something, rather than a component?
The production Debian dbgsym infrastructure seems to have the same
three components (aka archive areas) as the main Debian archive, namely
main, contrib and non-free.
I don't think reprepro can or should mimic dak's output accurately,
because dak creates a separate lookaside apt repository for detached
debug symbols, but the scope of reprepro is that it deals with a single
apt repository.
Because reprepro can already accept *-dbgsym_*.deb and will currently
list them alongside any other .deb, moving Debian-built (.deb) -dbgsym
packages into a separate suite, component or repository would arguably
be an incompatible behaviour change.
smcv
