Bug#728198: devscripts: debuild (& others) must reject debian/rules actions on unpatched source trees

[Ximin Luo]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 897 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/devscripts-devel/attachments/20131029/74d49fc2/attachment.sig>