Merging from Debian with patches applied

Dmitrijs Ledkovs dmitrij.ledkov at gmail.com
Wed Feb 17 13:48:35 GMT 2010


On 17 February 2010 13:26, James Westby <jw+debian at jameswestby.net> wrote:
> On Tue, 16 Feb 2010 16:19:20 -0600, John Arbash Meinel <john at arbash-meinel.com> wrote:
>> To make sure I understand. If you use quilt, it moves the location on
>> the patch stack (by reverse applying the patches). Leaving you with a
>> working dir that doesn't have the 'newer' patches applied. Then if you
>> change stuff and "build", it recomputes the current patch.
>
> Yes, I'm not sure if that's automatic, or whether you are expected to
> "refresh" and then "pop" back to the top of the stack.
>

With my little experiments with v3 quilt yes that's what expected
"refresh & push -a" cause otherwise it will try to push them itself
and possibly get source package build error cause it can't push a
patch.

<snip idea>

I truly dislike patches and i'd rather use native tools.

dpkg-source has an option to generate just a single static flat patch
where it compares the tree with orig-tree and stores binary & debian
packaging into debian.tar.gz and generates just one patch for the rest
of the modifications. This is targeted at *-buildpackage people who
have topic branches to manage patches ;-) *hint* *hint*

It can use a static header file where you generally point where you
can find VCS or something else which is used to manage patches
separately and sanely.

Import quilt patches into pipelines and somehow get the pipelines back
when you branch lp:ubuntu/package. And force use a single-patch at
source package generation. Going forward we will be building out of
the branches and this way it's much easier to work with all the
different patches.

Just a thought but needs backing/support on pipelines (or looms). And
the associate patches.ubuntu.com & Debian backfeed collaboration
support. Cause this kind of looks like Renaissance of
no-patch-system-used except that we are not using static local folder
but a VCS tip.

ps. I really don't want to see diff of diffs again in $bzr diff. My
eyes hurt.....



More information about the ubuntu-distributed-devel mailing list