I missed this first mail, argh. So this is a reply to both. On Sun, Mar 20, 2005 at 11:01:41PM -0500, David Nusinow wrote: > 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]. I think this is a bad idea. > > 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. Having used multiple systems now, including: * bare (i.e. monolithic .diff.gz), * dbs (in all its forms), * cdbs simple-patchsys (mainly with dbus), * dpatch (including with Ubuntu's incredibly complex kernel packages), * my own custom hack, * Arch branches, I think that DBS is the only option for xorg. I just haven't seen anything which handles the sheer volume of patches (Ubuntu's xorg packages currently have 81,806 lines of patches) that we have in an even acceptable manner, except DBS. Wedged trees are very easy to deal with, and the ability to just throw away the build tree, and restart (including reapplying the patches) with a minimum of effort is very important to me. I shouldn't have to take the Debian directory with me, realise that it's full of stamps, etc. For all its flaws, DBS is very good at keeping state, and I have never, ever had a situation whereby I couldn't easily get back to where I wanted to be with it. I have encountered this situation with all other systems (including single-diff situations, where the main way to get wedged is by ending up with a .diff.gz which bears no resemblance to what you have in debian/patches). > > 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. Yes. > > * 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. Or just committing them -- of the people in this discussion, myself, Branden and Fabio have upstream commit access. And in fairness to dpatch, every dpatch I've yet seen is just a diff wrapped in a shell script. > > * 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. Yes. > > 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 The patches ... ? I have no desire to maintain a massively-forked version, either; I have been rather aggressively submitting patches upstream. Of the 81k quoted figure above, 51,106 are in the 'stolen from upstreams' category (HEAD, Mesa, unichrome.sf.net and linuxwacom.sf.net). Which still leaves us with a hefty, but reasonably manageable, 30700 lines. FWIW, we were over the 320,000-line mark with xfree86 4.3.0.dfsg.1-6ubuntu25. > > 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: I think it's a nice idea, yes. However, I don't think that this should be an overriding concern. In fact, if it has a significant enough impact on the maintainability of the package by its regular maintainers, then it's actually a step backward. I don't think that the X tree in general is significantly comprehensible to people unfamiliar with it that having a slightly lower barrier to entry in terms of the Debian packaging (why not just a very brief top-level README?) is a huge benefit -- the tree on its own is still huge and unwieldy. In any case, it's very easy for people who *know* the system you're proposing to get messed up and end up with a wedged tree (see my definition of 'wedged' for this case, above), let alone people who just see it and go 'ah! unpacked source! let me hack'. > > $ svn diff http://necrotic.deadbeast.net/svn/xorg-x11/vendor \ > > http://necrotic.deadbeast.net/svn/xorg-x11/trunk I think that depending on a specific revision-control system is a horrible idea. I also think that depending on your bandwidth, and being online, is a horrible idea. I don't like the idea of needing to run a SVN command that will quite likely kill my entire bandwidth, when I could simply run diff myself. Are there alternative ways to do this? > > 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. Agreed. > 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. Last I saw, there was an environment variable? man quilt had it, IIRC. > > 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? That makes two of us. > > 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 is very distinctly similar to DBS, except that your entire tree is the working copy, so you can't just copy around a couple of directories. I do not see how this is any easier than DBS; indeed, I would posit that it's more difficult, and infinitely more annoying. And about a hojillion times more prone to failure. What about people who do not have SVN commit access? How are they expected to maintain changes externally? Your entire system seems rather dependent on a closed-access repository. > > There are several opportunities in the above for human error to creep > > in. > > I'm not sure if quilt mitigates any of these. I believe that DBS mitigates these, because if you screw up, you either get a failure on build, or your patch isn't there. There is no opportunity for the working xc/ and orig+debian/patches to become desynced, at all. And I'm entirely pessimistic about the ability of anyone -- and this is no slight on anyone here; god knows I'd do it -- to keep this entirely synced. > > 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. Apparently dbs-ng has dependencies like this; for now, depending on LC_COLLATE sorting things the way you want seems to be the accepted way to do things. I don't think it's terribly broken as such, just annoying sometimes. > > 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: > > > > [snip process you don't like] > > > > (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. Right. In DBS, this is 'rm debian/patches/xxx_foo.diff'. > > 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? Can I make what might be a stupid suggestion? You say in all this that your concern is transparency -- what about if there was an automatically-generated xc/ tree somewhere (say, gluck), which had build-tree/xc/ from a debian/rules setup run, regenerated every upload? > > 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. Um, dbs. > 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. I'd have to see a working proof-of-concept implementation to be compelled: I've seen the current (NIH?) repackaging of xorg and I'm extremely unimpressed so far, and I think it is nothing short of completely unmaintainable. From where I stand, I'd like to see a sample implementation using quilt to see the other options, but I honestly can't see myself moving my xorg packages away from dbs if quilt doesn't seem to be compelling. Cheers, Daniel
Attachment:
signature.asc
Description: Digital signature