Hi, could you please comment on the proposal? I'm blocked in some aspects right now due to this. Thanks, Emilio Emilio Pozuelo Monfort wrote: > 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