On 29/10/13 16:35, Russ Allbery wrote: > Ximin Luo <infini...@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
signature.asc
Description: OpenPGP digital signature
