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

Automatic Debug Packages Creation and Handling

Hi folks,

As I already wrote to you back in April, I wanted to propose a GSoC project to
automatically create debugging packages for the Debian archive. In short, I got
accepted and have started (a bit late due to exams) it. Here's to let you know
about it and ask for comments. Right now everything is just a tentative plan, so
please speak up!

The idea is:

We allow to upload .ddeb packages to be uploaded to ftp-master (the file would
be listed in the .changes file). Then when dak processes the files, moves the
.ddebs to the debug archive, and we ship them there as a normal deb archive.

In order to automatize the process, we'll modify the helper tools (debhelper and
CDBS) so that packages with arch:dep packages automatically create a .ddeb
package (and add it to the .changes file). This won't be the case if there
already are -dbg packages, and we will provide an option to disable this (in
case it's not wanted for whatever reason). Those packages shipping -dbg binary
packages can remove these, and immediately they will have .ddeb packages.

For packages not using helper tools, they can still build the .ddebs manually.
I'm sure that won't be a problem, as their maintainers surely like to do things
manually :)

After we have got the repository with the ddeb packages, we can ship the
debugging symbols unpacked through a webdav mount (or some other way) using the
Build-ID mechanism. That way people can mount it and immediately have all the
debugging symbols available (they would be downloaded as needed on the fly).

Now to the specifics:

- There's the question as to whether build one .ddeb per source package, or one
  per binary package. The latter has the advantage that if you want to debug,
  say, OOo Writter, you don't need to get the debugging symbols for all the
  other things shipped in OOo. However that would create too many .ddebs.
  One source package doesn't have this problem, but has the one of being a bit
  harder to avoid to have somebody with mismatching versions for the .ddeb and
  the packages the .ddeb provide symbols for. This could be handled with
  Conflicts though. So one .ddeb per source package sounds like a good option.

- As to the question I had back in April of whether to build the .ddebs only
  in the buildds or everywhere, it's pretty clear to me now that we should go
  with the latter. That way we don't need to divert packages, and builds are
  reproducible everywhere. Also this way we will have a .ddeb for the
  architecture the package is uploaded (e.g. you upload
  foo_1.0-1_i386.changes, you will have a .ddeb for i386, but the other way
  you wouldn't). The only downside of this is that in many cases (when you don't
  have a -dbg package) the upload will be bigger. Hopefully that's not a big
  problem. I'll mail debian-devel@ asking for comments once I know what you
  guys think.

I don't think the wanna-build folks will be affected (as in tools that need to
be updated) by these changes, but I'm not very versed wrt buildd stuff. If
that's not correct, please let me know!

The ftpmasters would be affected AFAICS by accepting the .ddebs and moving them
to the debug repository.

I haven't looked into the dak code yet, but will start to look at it soon. I
already have working patches (although not very polished yet) for debhelper and
CDBS though. I wanted to have some working code to start with!

Please let me know what you think about the proposal.

Best regards,

Attachment: signature.asc
Description: OpenPGP digital signature

Reply to: