On 29/10/13 16:35, Russ Allbery wrote:
> Ximin Luo <infinity0@gmx.com> writes:
>
>> It depends on what you consider as "part of the build process". Now that
>> you are deprecating the "patch" target, I would argue that "ready to
>> build" and "ready to modify" are the same thing - since `dpkg-source
>> --before-build` applies the patches, which is also what you want to be
>> able to modify the sources.
>
>> Do you have some counter-examples?
>
> Not off-hand, but they are definitely not the same thing. There are still
> packages that use format 1.0 and separate patch systems. While that may
> be deprecated, it's still supported, and I expect it to be supported for
> quite some time into the future.
>
>> I'd like to suggest the additional requirement for debian/rules targets
>> to assume that all patches have been applied.
>
> There was extensive discussion of this on debian-devel, and the short
> answer is that the project does not have consensus to make this change.
> I also don't think that this is a fight worth having right now. Some
> people are very insistent on continuing to use more complex build systems
> in conjunction with the 1.0 package format (and the 3.0 (quilt) format
> does have some weird corner cases that make some things harder to
> understand).
>
By "patches" I mean things that are integral to the definition of the source format, that are handled by `dpkg-source --{before,after}-build`. It seems that 3.0 (quilt) patches are strictly "external" to the build process (things done with debian/rules) whereas patches in other systems are done "within" the build process. If this conceptual separation is accurate, I don't see the problem with requiring that debian/rules targets assumes that "`dpkg-source --before-build` has been done".
Of course, I don't understand 3.0 (quilt) fully, so I may be missing some of these "corner cases".
--
GPG: 4096R/1318EFAC5FBBDBCE
git://github.com/infinity0/pubkeys.git
Attachment:
signature.asc
Description: OpenPGP digital signature