Re: recommendations wanted for new patch management system in xorg-x11
Hi all,
On Sun, Mar 20, 2005 at 03:13:16PM -0500, Branden Robinson wrote:
> 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. :)
Good to hear. I agree with Fabio's assesment as well, btw.
> 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.
Ok, I'll be the obligatory shill for quilt, which I've come to enjoy using on
my own packages. Be wary though, I haven't used it for anything on the scale of
the X packages, so I very much want to to hear areas where it falls short.
> 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.
Agreed.
> * 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.
The patches kept in quilt are simple diffs, as you'd expect of a patch. No
weird patch-script thing like dpatch. As such, they could be easily extracted
(a simple cp will do it) or merged to be submitted to upstream.
> * 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.
Oh yeah.
> 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.
Same justification as above. The patches
>
> 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 \
This is simple to do with quilt. You simply apply all your patches and leave
them that way when you build.
> 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.
Unfortunately, I haven't figured out how to put the patches in debian/patches,
but they do all go in the patches directory, so it's still simple to handle.
> 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.
I'm not sure what sort of requirements outside the ones in this mail are. Could
someone clarify this please?
> 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.
This seems similiar to quilt.
1) If you want, you can snapshot your current source (quilt snapshot).
2) If it's a patch from elsewhere you simply use quilt import (maybe a
quilt new if you want to combine multiple external patches in to one
internal patch)
3) If it's not an external patch, you use 'quilt add' for each file you're
editing manually and edit your files. When you're finished you run 'quilt
refresh' and it generates your patch from the files you added. The patch
goes in to patches/ and the name of the patch gets put in the stack,
which is a simple list in patches/series.
4) Run 'quilt pop -a' and 'quilt push -a' to get a pristine tree and then
to apply all patches, including the one you just made to ensure it all
applies cleanly.
5) svn add ; svn commit as above
> There are several opportunities in the above for human error to creep
> in.
I'm not sure if quilt mitigates any of these.
> 4) A patch dependency mechanism would be cool, but is not essential.
Quilt does have the concept of patch dependencies, although I haven't worked
with them. The "quilt graph" command will generate a dotfile for graphviz
displaying how patches will depend on each other. The way it would track
dependencies beyond that is that they are still organized as a patch stack, so
patches that are depended on are lower in the stack than those that are doing
the depending. This is limited though in comparison to a tree model (not sure
if dbs's next revision will have a tree) but might still meet the criteria. At
the very least, you could use quilt graph to examine which patches need to be
applied manually and then simply 'quilt push' the top one.
> 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.)
Ewwww. For what it's worth, quilt makes it easy to remove patches and in
generaly you just apply whatever is in the stack and get rid of patches that
aren't going to be applied.
> 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?
I'm interested, although I haven't spent much time in the X.org bugzilla yet.
> 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.
Vote [1] quilt :-) I'm definitely interested in hearing alternate options. I'm
leaning away from the next dbs simply because it doesn't exist yet. I also
dislike dpatch because the weird hybrid script/patch thing is hard to work with
when you want to do some things manually. I'm open to hearing other options
though.
- David Nusinow
Reply to: