Manoj Srivastava <[EMAIL PROTECTED]> writes: > On Fri, 21 Dec 2007 16:24:02 -0800, Russ Allbery <[EMAIL PROTECTED]> said:
>> I need to be able to maintain a ton of small patches in an easily >> separable form that often will never be merged upstream, while doing >> the absolute minimum of work to pull those patches forward each time a >> new upstream version is released and still keeping each change >> separate. quilt does this perfectly. All explanations that I've seen >> so far on how to do this with git or arch are more complicated and >> slower than my workflow with quilt. With quilt, the typical upgrade >> is: > >> * import new upstream source (done in the underlying VCS) >> * quilt push -a >> * repeat for each failing patch until no patches fail: >> - if quilt says patch was applied upstream, quilt delete the patch >> - otherwise, quilt push -f <patch>, resolve conflicts, quilt refresh >> * quilt pop -a >> * commit results > > Heh. Here is my work flow. > * tla_load_dir (in the upstream branch) > * arch_upgrade (might have to run again, if I had to deal with > conflicts the first time) > > Done. > > Seems like much simpler than the quilt thingy. windlord:~> which arch_upgrade arch_upgrade: Command not found. You realize this is kind of an unfair comparison, right? :) I was comparing the native tools, not the native quilt tool against the machinery and automation you've written on top of arch for yourself over the years. It may be that arch plus your tool set would be simpler, although it sounds like arch plus your tool set is basically exactly my work flow with quilt. > Err, a patch requires me to think, and It can't just be compiled > automatically, for each branch. This is subjective. I find patches > far harder to deal with in practice than separate branches. I can > inspect the code straight out, rather than have to mentally manipulate > the code _and_ a patch. If I need a patch, the VCS can generate it, so > I don't lose out there either. Maybe some of it just amounts to being familiar with different tools and being used to different ways of thinking about code. For all of this, including the parts I snipped, I hear what you're saying, but your way still seems more complex to me and I'm just not convinced. Anyway, it's mostly irrelevant, because.... >> I'm continuing to object to adding wording to Policy that discourages >> people from using patch systems such as quilt or dpatch -- that's >> where this all started. > > Oh, I agree there. Policy should ever say things about what > tools people can use (umm. I am tempted to ban vi and derivatives in > policy ... nah). *heh*. > Policy should be able to specify that there should be a simple > mechanism to get to the sources that will be compiled, preferably > without having to trust code that needs to be run as privileged users > or is different from what will be run during the build process. > > So, while we might not want policy to say that people should not > use quilt; we might want to be able to say that when I do dpkg -x > *.dsc; what I get is what is gonna be compiled. Well, if you say that, you're basically discouraging quilt, because that's not how quilt works. The default state with quilt needs to be with patches unapplied, not with patches applied. Otherwise, if you want to use quilt rather than ignore its existence, you'll very quickly get your tree into an inconsistent state. If you ship the Debian source package with all the patches already applied, modifications made in that state are modifications to the top patch, which is almost never what you want. There are a bunch of other patch systems that work this way as well. I'd rather deal with them by having some sort of debian/rules target that puts the source in a state that people want, as was the original suggestion, than to try to tell people not to use them in their most reliable mode. As I said back at the start of this, one advantage of shipping a DVCS repository is that it better supports this model of immediately starting to modify things. Although I'll point out that if you want to actually *use* the DVCS, you still don't want to do that, because you'll be editing things in the wrong branch. You still want to create a branch first. So the degree to which it better supports this model is somewhat dubious; as with quilt, it only really supports it if you're willing to ignore the workflow and put the tree into a weird state. Anyway, the security team and the release team, however grudgingly, seem to be willing to deal with quilt (and dpatch). I really don't think it improves Debian to discourage the way in which quilt and dpatch are already being used in the project. The only real improvement would come from having everyone adopt the same set of tools (such as Ubuntu standardizing on bzr) so that we always know what to expect. If we all end up loving git, maybe that will happen, but I don't think we're there yet. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
