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, Emilio
Attachment:
signature.asc
Description: OpenPGP digital signature