Excerpts from James Westby's message of Tue May 17 02:08:47 UTC 2011: > On Mon, 16 May 2011 22:18:37 -0000, Clint Byrum <cl...@fewbar.com> wrote: > > There's not much we can do if the source package patches conflicts > > directly with upstream. The build log is quite clear which patches won't > > apply, so they can be selectively removed if some need to stay. Ultimately > > you have 4 different versions of the code: > > > > 1 upstream .orig > > 2 upstream .orig + packaging patches > > 3 upstream NEW + packaging patches > > 4 upstream NEW > > > > Picking which one to build could be simpler, thats true. But the problem > > is that there's some conflicting, duplicated delta between 2 and 3 that > > must be hand merged because the patches are not applied, so the common > > version is unknown. > > > > I stand by my original assessment, that while its not easy, its necessary > > to be able to be clear about which patches you want to apply. > > Is there some confusion here? This case isn't about updating the package > to a new upstream release. This is just about rebuilding the current > Ubuntu package, so what's in debian/patches should apply, otherwise the > packaging is broken. > > What is causing the issue is that debuild and bzr-builder apply the > quilt patches in slightly different ways, with bzr-builder failing if > the patches are already applied and there is no .pc directory, and > debuild no failing in that case. > > It's my opinion that when using bzr + dpkg v3 (quilt), the bzr tree > should have patches applied and a .pc directory, as that allows you to > directly work with quilt when getting the branch. However, given that > debuild accepts the current branch as input, bzr-builder probably should > too, as it isn't really doing anything different. > > This is yet another case where the mismatch between quilt patches and > bzr bites us, so I'd like for it to go away by natively supporting > changes against a base in bzr.
I see, apologies to those I misunderstood. So yes, I think bzr-builder should employ the same standards as debuild, since it is the de-facto way packages are built, while builder is trying to emulate it. It would also make sense that bzr-buildpackage would warn the user that their package has changes applied, but no .pc directory. Even better would be if it could actually *create* that .pc directory, as I am somewhat confused as to how to do that simply. -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to cloud-init in Ubuntu. https://bugs.launchpad.net/bugs/766242 Title: lp:ubuntu/cloud-init is not buildable by bzr-builder -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
