Marc Haber wrote: > On Thu, Jun 16, 2005 at 06:46:04PM +0200, Daniel Leidert wrote: > > Let's say, we are working in the source tree of a Debian package and ran > > build target, so the patch/patch-stamp target was called. The source is > > now patched. Now you maybe see a mistake and you want to edit an > > existing patch. Running dpatch-edit-patch, modifying and saving the > > patch now leads to the following situation: The patch is modified in > > debian/patches, but the old patch is still applied to the source, because > > the clean target (unpatch target) is applied to the directoty in /tmp, > > not to the real source. Trying to call the unpatch target (e.g. with the > > clean > > target) now fails, because the patch cannot be reverted. The only chance to > > run unpatch target is to apply manually the changes made during the last > > patch-change to the source too, fix debian/patched and then try to call > > unpatch target again. Maybe dpatch-edit-patch should check for the > > existence of debian/patched inside the source and apply the unpatch > > target to the source if debian/patched is found. > > I do not quite understand what you mean. Can you give a trivial > example, preferably in form of a typescript?
Situation: a clean source tree of a debian package /home/user/package_source-a.b, dpatch is invoked in debian/rules, at least one patch exists (lets say debian/patches/01_patch_1.dpatch). dpkg-buildpackage ... builds the package. 01_patch_1.dpatch is applied to the source, right? Now you see, you missed to patch something and you want to fix this: dpatch-edit-patch 01_patch_1 This creates a work- and a reference copy in /tmp (tmp/dpep-work.xyz/package_source-a.b and /tmp/dpep-ref.zyx/package_source-a.b), right? Now you make your changes and then type exit. The patch is saved to /home/user/package_source-a.b/debian/patches, your real working directory, which was never cleaned. And if you now try to run fakeroot debian/rules unpatch dpatch tries to revert the changes made by /home/user/package_source-a.b/debian/patches/01_patch_1.dpatch and this fails, because this is the updated patch, which was never applied to /home/user/package_source-a.b - the old version of 01_patch_1.dpatch is still applied to your working directory. And this causes trouble and probably (depending on the size of the patch) a broken work directory /home/user/package_source-a.b. > dpep copies your current source to the "reference copy", and then runs > debian/rules clean in the reference copy. The reference copy is then > copied once more to the work copy, which you edit. After exiting the > shell, the diff between reference copy and work copy is then saved to > the patch file name. Yes, but both live in /tmp. > The invocation of the debian/rules clean target after creating the > reference copy should remove all your patches so that you start from a > clean copy. Yes, but only in /tmp. The clean target is not invoked inside your real working directory (as it was done till dpatch 2.0.10) and this causes trouble, if your working directory is patched and you want to change an existing (applied) patch. The only workaround is: Before running dpatch-edit-patch to edit an _existing_ patch, you must run fakeroot debian/rules unpatch to make sure, the patch you want to edit is not applied. I hope, this explains the problem a bit better. Regards, Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
