Hello, Emilio Pozuelo Monfort [2009-07-03 0:25 +0200]: > In order to automatize the process, we'll modify the helper tools (debhelper and > CDBS) I don't think you should rely on CDBS for that. In Ubuntu's implementation, we currently divert dh_strip, so we just rely on debhelper. > This won't be the case if there already are -dbg packages, and we > will provide an option to disable this That's a good thought. In Ubuntu, we always produce .ddebs so that our crash reprocessing tool just needs to know about one approach. However, if that is accepted, I'd much rather ban -dbg files completely. They clutter the mirrors, package searches, inflate Packages.gz, etc. > - There's the question as to whether build one .ddeb per source package, or one > per binary package. I vote for the latter, for two reasons: * Users think in terms of binary packages. * Often, source packages multibuild the same thing with different options (think of the mplayer-k6 vs. mplayer-686 packages in the past, or exim4-daemon-light vs. -heavy). You can't install both of the debug symbols at the same time. > 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! BTW, you are aware of https://launchpad.net/pkg-create-dbgsym ? It's the implementation we have successfully used in Ubuntu for years, with test cases and fixes for many obscure and broken packages. I think a reimplementation from scratch should rather be avoided, unless you want to completely redesign the solution? Thanks, and good luck! Martin -- Martin Pitt | http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
Attachment:
signature.asc
Description: Digital signature