Hi, There are some interesting edge cases emerging from our experience of merging the new source package formats from Debian.
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. 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. 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. 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). 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 -- ubuntu-distributed-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
