On Sun, Mar 20, 2005 at 03:13:16PM -0500, Branden Robinson wrote: [...] > Okay, with that preface in place, I'm seeking a patch management system > with the following properties: > > 1) The system should cleanly support shipping a .diff.gz with all the > patches applied to the source tree.
I do not understand why this is a requirement, because this can be achieved with any patch management system. > Some people have said over the years that "dpkg-source -x" is all > that a person should have to do to get a look a Debian source tree > as it will actually be built, and I share that sentiment. Agreed. For the record, Junichi Uekawa blogged a bit about this issue http://www.netfort.gr.jp/~dancer/diary/200503.html.en#2005-Mar-24-06:42:34 and I faced a very similar problem when displaying l10n statistics pages for PO files (fortunately this does not apply to po-debconf), see http://www.debian.org/intl/l10n/po/todo When PO files are patched, it is almost impossible to provide up-to-date PO files without building the package, which is why dbs managed packages are not listed. A better solution would be to exclude packages only if they patch PO files, but I never got time to implement that ;) > Furthermore, keeping the patches applied to the > trunk in SVN enables one to essentially generate a Debian diff on > demand: > > $ svn diff http://necrotic.deadbeast.net/svn/xorg-x11/vendor \ > http://necrotic.deadbeast.net/svn/xorg-x11/trunk \ > > 2) Patches should reside in a distinct and obvious location, like > debian/patches. Every patch management system I know of support this, > but it's a criterion nonetheless. Ok. > 3) The patch development process using the patch management system should > be straightforward enough to be easily applicable to X Strike Force > requirements and documentable within that context. > > The process one would have to use with the current apply-patches and > revert-patches targets is workable, but somewhat cumbersome, and > involves more steps than I'd like. Basically, once you've identified a > patch you want to apply: I will explain how this can be achieved with quilt. Here is what I did to use quilt for this mini-tutorial: $ apt-get source xfree86 $ cd xfree86-4.3.0.dfsg.1 $ tar zxf xfree86-4.3.0.tar.gz $ rm xfree86-4.3.0.tar.gz Now let's introduce quilt in the room $ export QUILT_PATCHES="debian/patches" $ cd debian/patches Quilt lists its patches in a file called 'series'. Current patches have no prefix, whereas -p1 is the default for quilt, so add '-p0'. $ ls *.diff | sed -e 's/$/ -p0/' > series $ cd ../.. We are ready now! > 1) You run revert-patches to restore your checkout to a "pristine" > state; Apply all patches: $ quilt push -a Applying patch 000_post430.diff patching file xc/config/cf/Imake.tmpl patching file xc/config/cf/NetBSD.cf [...] Applying patch 914_debian_Xserver_send_bugs_to_us.diff patching file xc/programs/Xserver/hw/xfree86/common/xf86Init.c patching file xc/programs/Xserver/hw/xfree86/drivers/tseng/tseng_driver.c Now at patch 914_debian_Xserver_send_bugs_to_us.diff Revert all patches: $ quilt pop -a Removing patch 914_debian_Xserver_send_bugs_to_us.diff Restoring xc/programs/Xserver/hw/xfree86/common/xf86Init.c Restoring xc/programs/Xserver/hw/xfree86/drivers/tseng/tseng_driver.c [...] Restoring xc/programs/xdm/greeter/greet.c Restoring xc/programs/xdm/greeter/verify.c No patches applied > 2) You manually apply any patches that would be prerequisites for the > one you're about to apply; You want to add a fix to 061_savage_driver_1.1.27t.diff: $ quilt push 061_savage_driver_1.1.27t.diff Applying patch 000_post430.diff patching file xc/config/cf/Imake.tmpl patching file xc/config/cf/NetBSD.cf [...] Applying patch 061_savage_driver_1.1.27t.diff patching file xc/programs/Xserver/hw/xfree86/drivers/savage/savage_accel.c patching file xc/programs/Xserver/hw/xfree86/drivers/savage/savage_cursor.c patching file xc/programs/Xserver/hw/xfree86/drivers/savage/savage_dga.c patching file xc/programs/Xserver/hw/xfree86/drivers/savage/savage_driver.c patching file xc/programs/Xserver/hw/xfree86/drivers/savage/savage_driver.h patching file xc/programs/Xserver/hw/xfree86/drivers/savage/savage_regs.h patching file xc/programs/Xserver/hw/xfree86/drivers/savage/savage_vbe.c patching file xc/programs/Xserver/hw/xfree86/drivers/savage/savage_video.c Now at patch 061_savage_driver_1.1.27t.diff All patches prior to 061_savage_driver_1.1.27t.diff in debian/patches/series have been applied. At this point, you can either: a. Edit this patch. b. Add a new patch after this one: $ quilt new 062_savage_another_fix.diff Patch 062_savage_another_fix.diff is now on top You can now see that this new patch has been inserted into debian/patches/series at the right place. Editing patches is a little bit strange at first. You need to tell quilt which files you are going to edit: $ quilt edit xc/programs/Xserver/hw/xfree86/drivers/savage/savage_accel.c [Perform your changes] File xc/programs/Xserver/hw/xfree86/drivers/savage/savage_accel.c added to patch 062_savage_another_fix.diff $ quilt refresh Refreshed patch 062_savage_another_fix.diff Now 062_savage_another_fix.diff contains your new changes. Quilt stores original files in a top-level .pc directory, but only those which are patched, and each patch has its own directory. This is why we have to tell quilt which files it needs to keep track on. An alternative is $ quilt add xc/programs/Xserver/hw/xfree86/drivers/savage/savage_shadow.c File xc/programs/Xserver/hw/xfree86/drivers/savage/savage_shadow.c added to patch 062_savage_another_fix.diff It has then been recorded and you can edit it with your favorite editor instead of 'quilt edit'. Of course, all quilt commands have a '-h' command line flag to give some help. As said above, pop/push can navigate within patches. If changes have been performed without running 'quilt refresh', quilt complains: $ quilt pop Patch 062_savage_another_fix.diff does not remove cleanly (refresh it or enforce with -f) One can either run $ quilt refresh if one forgot to update 062_savage_another_fix.diff, or $ quilt pop -f to discard changes in 062_savage_another_fix.diff. > 3) You make backups of the files you're about to change; Quilt take care of backups, see above. > 4) You make your patch and store the diff in debian/patches; > 5) You manually apply any patches that would be affected by your changes > and repair fuzz/offsets/etc. by basically repeating steps 3) and 4), > updating debian/patches/* files as needed. > 6) You re-revert all patches you applied to get the checkout back to a > "pristine" state again; > 7) You run apply-patches and confirm that you didn't screw anything up > in steps 2) to 6); Steps 4-7 can be performed with pop/push/diff. Of course solving conflicts may be hard, but there are some nice features, e.g. you can ask which patches are modifying a given file: $ quilt patches xc/programs/xkbcomp/symbols/pc/us 000_stolen_from_HEAD_xkb_data.diff 099j_xkb_new_layouts.diff 099t_xkb_remove_hidden_attributes.diff So it is a good idea to first look at these patches before making changes. (Warning: only applied patches are taken into account) Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
