reopen 728198 reassign 728198 dpkg-dev retitle 728198 dpkg-buildpackage, debuild, et al, must reject debian/rules actions on unpatched source trees affects 728198 +devscripts
On 29/10/13 15:18, James McCoy wrote: > On Tue, Oct 29, 2013 at 12:14:16PM +0000, Ximin Luo wrote: >> It does not make sense to build or clean an unpatched source tree, since the >> applied patches are considered strictly *part of the source package*. >> However, >> `debuild build/clean`, and probably many other tools, still allows this to >> happen without any warning. > > This is not a bug in debuild. “debuild $target” should behave similar to > “dpkg-buildpackage -T $target” and as stated in dpkg-buildpackage(1): > > 1. It prepares the build environment by setting various environment > variables (see ENVIRONMENT) and calls dpkg-source > --before-build (unless -T or --target has been used). > … > 3. If a specific target has been selected with the -T or > --target option, it calls that target and stops here. Otherwise > it calls fakeroot debian/rules clean to clean the build-tree > (unless -nc is specified). > > From this, we can see that when a specific target is provided: > a) “dpkg-source --before-build” (which is what applies the patches) > should not be called and > b) “debian/rules $target” will be called directly and then the build > will stop. > > The expection when a specific target is going to be run is that the > working tree is in a proper state to run that target. > > When a target isn't specified, debuild runs dpkg-source > --before-build/--after-build just like dpkg-buildpackage does. > > This has previously been discussed in #628481[0]. > > [0]: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=628481#16 > > Cheers, > I'm sorry, closing this bug is a lazy cop-out that ignores a legitimate usability issue. Right now I cannot easily cleanup after a build; I do not want to use -tc because I'd like to examine the build products manually first, and manually running `dpkg-source --{before,after}-build` is usability bullshit. I agree there is an "expectation [..] that the working tree is in a proper state", but this is enforced no-where by the user-facing tools. Fixing the behaviour as I suggested DOES NOT BREAK ANYTHING, since it simply puts the tree into the state it is *supposed to already be in*. What's more, it might even expose subtle bugs where maintainers are incorrectly depending on a non-patched tree, for example #728097. That bug would not even exist if this issue had been properly detected by the build tools. X -- GPG: 4096R/1318EFAC5FBBDBCE git://github.com/infinity0/pubkeys.git
signature.asc
Description: OpenPGP digital signature
_______________________________________________ devscripts-devel mailing list devscripts-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/devscripts-devel