debian-de...@liska.ath.cx (Olе Streicher) writes: > James McCoy <vega.ja...@gmail.com> writes: >> On Wed, May 16, 2012 at 04:23:05PM +0200, Olе Streicher wrote: >>> Unpatching the sources *before* the build process was cleaned up makes >>> no sense to me at all. Could you provide a use case for that? >> As was described in #649531: >> >> vcs clone <repository with unpatched source> >> cd repo >> ... tweak a little ... >> dpkg-buildpackage; # applies patches, builds, and unapplies patches >> vcs diff; # looks good? >> vcs commit > > This works only for the special case that "build" does not change any > source file. Otherwise you would also commit the changed source files.
And it better not. There is no excuse for changing source files during build. If you need to change a file then that means that file isn't source anymore but generated. Try switching to out-of-tree builds if you have something like that. > Since for Debian you have only changes in the debian/ subdirectory, you > may do the following: > > vcs clone <repository with unpatched source> > cd repo > .... tweak a little ... > dpkg-buildpackage; # applies patches, builds, and unapplies patches > vcs diff debian > vcs commit debian > > this does not require unpatching, since it commits only the "debian" > subdirectory, which is not affected by any patches. > > Therefore, I don't see that the workflow you mentioned is a use case > that would require unpatching. > > [Quoting restored: Goswin wrote] >>>> What happens if you now call >>>> debuild patch >>>> to apply the patches in a 3.0 (quilt) package that has patch/unpatch >>>> targets? > >>> because it does *not* leave the sources in the same state. > >> Yes, it does. > > He wrote it himself: "patch" was meant as a target that *applies* the > patches. Therefore, it does not leave the sources in the same state > (since it applies the patches). I ment: It leaves the source in the same state it found it other than the side effects the called target(s) have themself. >> If you started with patches applied, then they will still be applied >> after calling "dpkg-buildpackage". If you didn't have patches >> applied, then "dpkg-buildpackage" will apply the patches, build and >> unapply the patches. > > We discussed the "debuild patch" option here which was introduced by > Goswin. > > Best > > Ole My main point, which I didn't explicitly state, is this: The way debuild/dpkg-buildpackage/dpkg-source currently behave allow maintainers to modify the behaviour by adding something to debian/rules. If the clean target needs the patches applied then debian/rules can easily make sure that they are. On the other hand if the clean target doesn't need the patches applied, as is the case for 99.9% of all packages then applying them would be wastefull. Personaly I try to set up all my packages in such a way that clean or no clean I can simply commit changes. That means that the build MUST not modify any source files (which is simply evil to begin with) and that you add a bunch of stuff to the ignore file (e.g. debian/files, debian/<pkg>/, debian/*.debhelper.log, debian/*.substvars, stamp files, ...). That is something you do once and after that clean or no clean you can simply commit. But that requires that patches are unapplied after build (unapply-patches in debian/source/local-options to enforce this). I usualy never call clean directly so the above problem can't even arise. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/8762btlniv.fsf@frosties.localnet