Comment 3 for bug 788349

On Thu, 2011-05-26 at 18:49 +0000, Barry Warsaw wrote:
> On May 25, 2011, at 10:08 PM, James Westby wrote:
>
> >On Wed, 25 May 2011 21:26:00 -0000, Barry Warsaw <email address hidden> wrote:
> >> Of course, it would be nice if bzr bd could do this for you, so you
> >> don't have to remember to do it, and so that you can't mess it up. I
> >> *think* bzr should be able to figure out the last Ubuntu version by
> >> looking at the tags. If the last version was not an Ubuntu version,
> >> then it should be possible to automatically supply -v to dpkg-
> >> buildsource, which forwards it to dpkg-genchanges.
> >
> >It's not possible for bzr-builddeb to reliably detect this. Check out
> >the --package-merge option. Try using this when you are building the
> >package in the situation you describe.
>
> I just tried this on python-support, where we have 1.0.10ubuntu3 and I'm
> merging up to Debian's 1.0.13 with an additional 1.0.13ubuntu1 to keep our
> Ubuntu specific changes. Looking in the _source.changes file, I see the
> changelog entries for
>
> 1.0.13ubuntu1
> 1.0.13
> 1.0.12
> 1.0.11
>
> which I think makes sense, given that the next change down is
> 1.0.10ubuntu3.
>
> So it looks like --package-merge is doing what I want, but I'm curious. Why
> is it not possible to reliably detect this? Does it make sense to always
> provide --package-merge or will that do bad things in some cases?
My guess is that perhaps it doesn't work properly if there are a few
entries in a Debian package that have not been uploaded (e.g. new
upstream releases for which a changelog entry exists).

Does --package-merge back off if -v was specified manually?

Cheers,

Jelmer