Russ Allbery wrote: > https://wiki.ubuntu.com/AptElfDebugSymbols is the specification. It does > use *.ddeb. There isn't any clear statement about how *.ddeb packages > differ from *.deb packages. It looks like, by and large, they don't, > except they may not need to contain the same set of things. The packages > are not in debian/control or the things fed from it, but are in *.changes. The format is the same of .deb packages, only the extension changes. > Ubuntu is creating one debug package per binary package, as I and a few > other people have said we prefer. However, they're using the > gnu_debuglink method, not the id method, so they don't have the one > problem with that method previously identified in this thread when the > same binary is copied into multiple packages. Nor the advantages. Anyway I don't care about one or many ddeb packages, convince the ftpmasters and I'll do one per binary package, resolving the build id file conflicts with replaces. > The debug packages depend on the packages for which they have symbols, > which solves the problem of not installing debug packages that both > provide symbols for the same binary. I don't get the problem, but I agree having one ddeb per binary package makes package relationships between ddebs and normal packages easier. > The proposal appears to only work for packages using debhelper, although > the steps are laid out so presumably they could be done manually if need > be. It's more complicated in their case because they do it only on the buildds by diverting debhelper (dh_strip to be precise). We, on the other hand, will modify debhelper directly so that ddebs are built anywhere. If you don't use debhelper, that's OK, as the proposal is not debhelper specific. You can magically build the ddebs with any other tools you want, or you can build them manually, and they will be accepted. > Ubuntu uses -dbgsym as the magic namespace. I don't know if it would be > good for us to do the same or to use a different namespace to avoid > problems for them in cases where we decide to build the package manually > via debian/control and debian/rules. I can ask Martin Pitt (who implemented and maintains the Ubuntu ddeb infrastructure), but it's just a detail to us. > It looks like the plan with *.ddeb is to treat them specially in the > archive software and divert them into a different tree in the archive > instead of using a separate archive area, which I think they're doing > now from that page. It also looks like one of the justifications for the > separate package is to hide them in the apt front-end so that users don't > see all the additional packages. I'm personally skeptical this is a good > idea, although I can see the merits of not returning them in apt-cache > search. That would be an apt change that I don't have in mind to do. We may or may not do it, but that's orthogonal to the topic I think. > Ah, and it looks like the automated crash reporting offers to download the > -dbgsym packages and install them. apport-retrace does that, yes. Would be nice to integrate apport in Debian (an ITP has recently being filled). Cheers, Emilio
Attachment:
signature.asc
Description: OpenPGP digital signature