As some of you may have noticed, I've dropped the build-dependency on
dbs[1] in the fledgling xorg-x11 SVN repository[2].
A couple of people, including Fabio, were confused by my intentions
regarding the "apply-patches" and "revert-patches" targets in the new rules
file[3].
I don't intend for those targets to be run as part of the normal package
build process -- they're intended for development convenience. Of course I
should have documented this in a comment, but I was in experimental hack
mode. :)
That said, the confusion presents a good opportunity to solicit the
knowledge and opinions of others on what patch management systems are now
available, and which one would be a good fit for the xorg-x11 packages.
Before I start, however, let me state a few premises:
* A coherent patch management system is a good idea, and far preferable to
a monolithic .diff.gz with no discrete separation of patches available.
* The presence (or usage) of a patch management system in the xorg-x11
source package doesn't mean that we shouldn't be submitting patches
upstream to freedesktop.org Bugzilla[4] as appropriate.
* A patch management system can be a good thing even if you're not applying
a lot of patches. You can realize benefits with it as soon as you apply
more than one patch to the upsteram source.
Therefore, please don't interpret this discussion as a desire to maintain a
fork of X.Org X11 for Debian that is dramatically different from the
original. I want it to be *easy* to get patches to upstream.
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. 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. 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.
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:
1) You run revert-patches to restore your checkout to a "pristine"
state;
2) You manually apply any patches that would be prerequisites for the
one you're about to apply;
3) You make backups of the files you're about to change;
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);
8) If you screwed nothing up, you SVN add the new patch and SVN commit
the whole group of changes (xc/ changes, debian/patches/, and
debian/changelog) together.
There are several opportunities in the above for human error to creep
in.
4) A patch dependency mechanism would be cool, but is not essential.
Coherent patch management appeals very storngly to me. I want it to be
easy for anyone to find out what the heck Debian is "doing" to X.Org X11.
Here's an example of a process I don't like:
* rpm -i whatever-1.2.3-4.RHEL.3.src.prm
* cd /usr/src/redhat/SOURCES
* ls, and see mountainous pile of patches to all kinds of upstream sources
using inconsistent naming conventions;
* find whatever.spec in this mess and carefully identify which patches are
identified as potentially applying to this package;
* read down further and see which patches are actually applied;
* reconcile inconsistent use of the -p flag to patch with the patch files
already present
(You can replace the first three steps with the bizarre tools rpm2cpio and
cpio[5], but they don't really help a great deal.)
Source package management in the RPM world is a mess. Debian stands for
excellence, and I'd like to make xorg-x11 an example of superior process
and superior technology.
Would someone like to help?
Please make a case for your favorite patch management system; when doing
so, please explicitly evaluate it against the criteria above, instead of
just saying "Have you heard of $FOO? I think that does everything you
want." Explain how.
I want to provoke discussion -- while I'm wearing my XSF leader hat at the
moment, I'd like to pick a technology that other people will enjoy using
(or at least be able tolerate). I'm pretty sure my ad-hoc
apply-patches/revert-patches targets don't qualify.
[1] http://packages.debian.org/unstable/devel/dbs
[2] http://necrotic.deadbeast.net/svn/xorg-x11/
[3] http://necrotic.deadbeast.net/svn/xorg-x11/trunk/debian/rules
[4] https://bugs.freedesktop.org/
[5] Does anyone know why Red Hat chose to base their package format on
cpio? Was it really just to be perverse and create a gratuitous
distinction between themselves and the .deb format, which even way back
in 1994 was based on ar and tar, IIRC? If you reply to this footnote,
please reply privately and/or retitle the thread.
--
G. Branden Robinson | Optimists believe we live in the
Debian GNU/Linux | best of all possible worlds.
branden@debian.org | Pessimists fear that this really is
http://people.debian.org/~branden/ | the best of all possible worlds.
Attachment:
signature.asc
Description: Digital signature