On 29/10/13 15:32, Russ Allbery wrote: > Ximin Luo <infinity0@gmx.com> writes: > >> I assumed that "extract to modified-build-ready" is the same as "extract >> to build-ready". In other words, if you can "edit" then "produce a >> modified package", then the you can also *not* perform the editing step >> and just "produce an unchanged package". Likewise, if the former step is >> impossible, the latter step is also impossible. > >> In what circumstance is my deduction false? > > The part where you only went one direction with your deduction. :) It's > true that a package ready to be modified is also ready to build. However, > what doesn't apply is the inverse. It's *not* necessarily true that a > package ready to build is the best state to be modified, and Policy does > not require that a newly-unpacked source package be in the best state for > subsequent modification (but does ask that the necessary steps be > documented). > 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? >> BTW, by "build-ready" I don't simply mean "`debian/rules build` >> succeeds" - if the patches aren't applied, then the build succeeds only >> by accident and not due to the intention of the maintainer. > > We do already require that dpkg-source -x followed by dpkg-buildpackage > results in a binary package with all patches the maintainer intended to > apply already applied. That's what the buildds do, so that's verified by > the archive build process. > I'd like to suggest the additional requirement for debian/rules targets to assume that all patches have been applied. You could argue it's already implicit, but it would be good to make this explicit. Another requirement would be for build tools to check that all patches have been applied, before doing any other action such as build/clean. I am having trouble convincing them over at bug #728198. You can think of "patch" as a similar step to "configure". It would be stupid to try to run "make clean" before "configure", since the Makefile doesn't even exist yet. Likewise, it would be stupid to try to run "debian/rules build" or "debian/rules clean" before "patch", only here it's not because the targets don't exist, but that the source tree isn't in the intended state. Not doing this check (or not running the rule that fixes the state) is equivalent to not doing a dependency check, it's just stupid. -- GPG: 4096R/1318EFAC5FBBDBCE git://github.com/infinity0/pubkeys.git
Attachment:
signature.asc
Description: OpenPGP digital signature