I thought some people here might be interested in the bug I just filed on dpkg-dev:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=572204 This was independent of the discussion in https://lists.ubuntu.com/archives/ubuntu-distributed-devel/2010-February/000508.html as I hadn't read that yet, but the second problem I mention in that bug is essentially the same thing. I realise the solution I propose isn't optimal given further bzr development, but I think it's the cleanest method that works right now even if the cost is losing bzr conflict resolution (which is annoying, but I'd rather that than have to mangle quilt patch files by hand or accidentally mis-refresh a quilt patch to include the upstream diff or any of the other things that can go wrong when you confuse quilt about its base file contents). Thoughts? I cannot agree with Dmitrijs that we should use the single-debian-patch mode, by the way. The first big package I converted to 3.0 (quilt), just this weekend, was openssh, and that was after very clear and definite feedback over the years from several different users (including at least one big customer) that they were finding it difficult to audit the source package. This is a source package with 6000+ lines of Debian patches, a substantial proportion of which by line count are (a) relied upon by many users and (b) never going to go upstream for various reasons which don't imply that they need to be removed from Debian. By converting it to the 3.0 (quilt) format, I was able to give them separated patches with distinct rationales and DEP-3 bug forwarding information, so that they can back out any individual patch they're uncomfortable with it. I've already had positive feedback from said big customer. They would have gained very little from the single-debian-patch model. Many people who look at source packages are not particularly familiar with bzr, and I don't think they should have to become familiar with some of the wilder and wackier corners of bzr in order (for example) to deploy openssh with the patch set they want; this is an obvious case of yak-shaving for a sysadmin. Even given fully integrated and polished looms or pipelines or whatever, debian/patches/ will still be a useful export format. What I want from bzr is simply to make the exported patch files easier to manage, not to collapse them all into one - I had that with the 1.0 source format and I only put up with it because at the time all the alternatives were worse. -- Colin Watson [[email protected]] -- ubuntu-distributed-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
