Hi! On Mon, 2013-06-03 at 21:13:23 -0400, James McCoy wrote: > On Tue, Apr 15, 2008 at 09:15:24AM +0200, Raphael Hertzog wrote: > > See #476100 for the reason. The lack of features in dpkg-bp resulted > > in a fork of it... > > > > I think it's clear that it's best to extend dpkg-bp to support everything > > that people need. The minimal set of features to add is the hook support > > so that debuild can at least become a wrapper of dpkg-buildpackage again. > > > > But I would favor going further: > > - also generate a .build file (with a mid-term interest to > > upload it with each binary build) > > - also cleanup the environment by default > > - add a configuration file so that we don't have to always retype > > "-khert...@debian.org" or "-us -uc -i -I" if we don't want to > > (the default options should appear in the build log however) > > Looking through the devscripts backlog, I came across the discussion in > #476100 and this bug. > > Since we're at the start of a release cycle, what are the chances we can > make some progress on moving functionality from debuild to dpkg-bp?
High, I was actually looking into the differences between debuild and dpkg-buildpackage recently when implementing no signing on UNRELEASED, and --force-sign support. > I'd be glad to help if there's some guidance on what should be moved to > dpkg-bp and/or what the next steps would be from dpkg's perspective. As I mentioned on this bug report, I don't think some of the features from debuild should be enabled by default, because dpkg-buildpackage gets used on build daemons for example, but support should certainly be added. Let me finish up the perl cleanup (to be finished before 1.17.0), and then I can come back to you in case there's anything missing. Thanks, Guillem -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
