On Wed, Oct 15, 2014 at 12:41:19PM -0400, Joey Hess wrote: > Mikko Rapeli wrote: > > 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. > > A better approach is to run dh_clean, which removes all debhelper cruft, > while leaving the package built. Assuming a sane Makefile, or a > debian/rules that uses build-stamp to work around a buggy upstream > Makefile, debian/rules binary can then be run again and will reuse what > has already been compiled.
Ok, I agree. dh_clean is the one that I should use then. Somehow I have managed to mix it with dh_auto_clean or 'fakeroot debian/rules clean' which often removes build directories but leaves some other temp files around. Maybe debhelper man page could somehow highlight the difference to dh_auto_clean but I can't put into a single sentence either. 'man dh_clean' says what this does so well. You can close this bug. Thanks! -Mikko -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
