Merging from Debian with patches applied

[John Arbash Meinel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


...

> 
> In short these formats ship the patches as a quilt series in
> ./debian/patches, but apply them when the source package is unpacked.
> If you then edit something and build it creates a new patch for you on
> top. If you want to modify an existing patch then you can use quilt to
> move to that patch and make your changes.

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.

> 
> When importing these packages we stick to the "bzr branch gets you the
> same as apt-get source" mantra and import with the patches applied.

I believe this means that you get a single snapshot with all patches,
and a list of patches that are managed by quilt, right? (What I mean is
that we don't import the series of patches, just the tip.)

> 
> Now when you merge from Debian in to Ubuntu you get bzr's merge
> capabilities helping you merge all the changes, which is great, but it
> doesn't help you change the contents of the patches that are stored.

Wouldn't it also potentially run into problems with conflicts in the
patch files themselves?

> 
> The first problem this causes is that you then might not be able to
> build the package as the first patch may now only apply with fuzz (which
> dpkg checks).

When you say "first patch" you mean the first patch against the
orig.tar.gz, right? And IIRC the issue is that Ubuntu's orig.tar.gz may
be a different version that debians.

> 
> Another issue is that the conflict resolution you do may in fact be
> altering one of the patches in the stack and so you would want to be
> doing it there, but that's not the obvious thing to do.
> 
> This isn't a problem specific to bzr, the scheme chosen by Debian isn't
> helpful to derivatives and so any method would have some of these
> issues, but we should fix it, even if it's in a bzr-specific way (though
> greater applicability would be useful).
> 
> I think we need to look at semi-automatically refreshing the stack of
> patches, but I'm not entirely sure how to go about this.
> 
> Ideas for how we can improve this situation would be welcome.
> 
> Thanks,
> 
> James
> 

Well, trying to integrate a DVCS with a patch workflow is a bit tricky
regardless. Because you don't know where in history a given patch would
apply. Consider if 2 patches overlapped in a section. (eg debian
provides a feature, and Ubuntu provides a bugfix for that feature.)


If we handled the patches as actual commits, then in theory we could
tell more accurately what part of the updates apply to what patch.
(Since they would be directly associated.)

Now I guess in both debian and ubuntu all changes vs orig.tar.gz have to
be represented by a patch. So in theory the 'merge' operation could
start at the beginning, and merge the 'orig.tar.gz' changes. Then it can
check to see if the first patch is identical on both sides, and if so,
skip forward (applying the patch). If they aren't identical, it could
ask the user do you want to:

a) apply just patch A and leave patch B in the queue to be applied later
b) apply just patch B and leave patch A in the queue to be applied later
c) apply patch A and remove patch B (patch A supersedes B)
d) apply patch B and remove patch A (patch B supersedes A)
e) apply both to create a new patch C

for (e) you may also have conflicts you want to resolve. A different UI
would be:

a) apply patch A to WT (and step the queue)
b) apply patch B to WT (and step the queue)
c) delete patch A from the queue
d) delete patch B from the queue
e) edit WT

The idea is that you decide which patch gets applied next as you
regenerate the patch series. This could actually interact fairly well
with bzr commits / a loom, but for starters it could just be an
interactive patch resolution.

I would probably have it start with a line like:

patch A applies (exactly/with fuzz), patch B applies (exactly/with fuzz)
patch A and patch B are identical

Then you would do
a d

(apply one and delete the other from the queue)

If it applied with fuzz, I assume you would regenerate the patch at that
point.

If the patches aren't identical, then you probably also want a few
possible displays:

1) show patch A as unidiff
2) show patch B as unidiff
3) show differences between A & B

All in all, this seems like a good place for a nice gui, since there is
enough stuff going on that you'd really like to have a fair amount of
assistance sorting it all out.

Does quilt support 'merging' 2 patch queues?

John
=:->

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkt7GegACgkQJdeBCYSNAAOREwCeMewJmRibXAaTCsNz0SEH1juQ
lqUAnibepIf9PfgBpBEHaG7+nom5sLK9
=Nu4U
-----END PGP SIGNATURE-----