Bug#765446: [debhelper-devel] Bug#765446: debhelper build target status file packagename.debhelper.log is not documented
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. -- see shy jo signature.asc Description: Digital signature
Bug#765446: [debhelper-devel] Bug#765446: debhelper build target status file packagename.debhelper.log is not documented
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
Bug#765446: [debhelper-devel] Bug#765446: debhelper build target status file packagename.debhelper.log is not documented
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. -- see shy jo signature.asc Description: Digital signature
Bug#765446: [debhelper-devel] Bug#765446: debhelper build target status file packagename.debhelper.log is not documented
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 debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
