On Wed, Oct 15, 2014 at 10:08:15AM -0400, Joey Hess wrote: > Mikko Rapeli wrote: > > debhelper build status log file is not documented in manual pages. > > Common developer use cases involve modifying list of installed files > > and package install scripts, and for these use cases a complete re-compile > > of the packages in not necessary. Instead developers could modify > > the package status log to re-execute all steps after build target, for > > example. > > I am not comfortable with encouraging this kind of hacking. It can > result in a package getting built while the modified source doesn't > build successfully, worse, has different contents when built straight > through from a clean build. > > So a developer might engage in this kind of hacking, test the resulting > binary package and see it's good, and then fire off a dpkg-buildpackage > and not test that clean build, and upload a broken package.
I have fought this issue for years. Build a package and then try to fix some bugs locally. Silly bugs like bad .install or package scripts should be straight forward to fix without complete rebuild of the package, which can take hours, or even days on smaller machines. If I add a simple fix to installed files or the scripts, another run with 'fakeroot debian/rules binary' doesn't actually do anything more when debhelper is used. The developer use case is different from what debian infrastructure does and yes proper builds need always be clean and start from scratch. But I see nothing bad in documenting a useful development feature like stepping back only few debhelper build steps without complete rebuild. -Mikko -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
