today's UEC report

[James Westby]

On Mon Oct 05 14:03:31 +0100 2009 Loïc Minier wrote:
> On Mon, Oct 05, 2009, Matt Zimmerman wrote:
> > Can someone point to a good example of a get-orig-source rule which does the
> > right thing for packaging directly from Bazaar?
> 
>  That worked in my limited testing:
> 
> BZR_REV := $(shell echo $(DEB_UPSTREAM_VERSION) | sed -n s/.*bzr//p)
> UPSTREAM_BRANCH := lp:$(DEB_SOURCE_PACKAGE)
> ifneq ($(BZR_REV),)
> get-orig-source:
>     bzr export -r$(BZR_REV) --root=$(DEB_SOURCE_PACKAGE)-$(DEB_UPSTREAM_VERSION)
>     $(DEB_SOURCE_PACKAGE)_$(DEB_UPSTREAM_VERSION).orig.tar.gz
>     $(UPSTREAM_BRANCH)
> endif

This isn't a policy-compliant get-orig-source rule unfortunately. get-orig-source
is specified such that it isn't very useful for this use-case.

>  but it would probably be more elegant to use bzr-builddeb to create a
>  tarball from the current branch (this would work because you keep
>  patches below debian/).
> 
>  bzr bd will try:
>  - to download the tarball from the archive
>  - if that failed, to run get-orig-source
>  - if that failed and in split mode, build from the current branch
>    excluding debian/
> 
>  Just use "bzr bd --split -S" to build a source package and that should
>  do the right thing (with or without get-orig-source).

I wouldn't recommend this, I would instead suggest that you use 
"bzr merge-upstream" to merge changes from the upstream branch.

If it is a release then

   bzr merge-upstream <URL of released tarball> <upstream branch> \
       [ -r <revision corresponding to release> ] \
       --version <upstream version>

will do the same as "uupdate".

If it is a snapshot then

   bzr merge-upstream <upstream branch> [ -r <revision to snapshot> ] \
        --version <upstream version>

will use a "bzr export" of that revision as the tarball. Unfortunately there
is no way to cope with any changes that are needed to a bzr checkout to get
the tarball (DFSGing, autoreconf etc.) We don't have a standard way to specify
this sort of thing in packaging that we can build upon. If this is needed for
the package the currentl best way to achieve this is to create the tarball
yourself and use the first form, but that just brings us in a complete circle.

The other difficulty with this is that it will try and find the tag from the
last time you merged the upstream code, if that is not present then it will
fail. The way to deal with this depends on how the branch has been managed
so far. It looks in this case as though 

   bzr tag -r 444.1.410 upstream-1.6~bzr854

would be the right thing to do here. (That's the revno of the point where
the upstream branch was last merged).

Thanks,

James