Re: recommendations wanted for new patch management system in xorg-x11
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
Reply to: