[Bug 766242] Re: lp:ubuntu/cloud-init is not buildable by bzr-builder

[Clint Byrum]

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 <clint at 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