Using version-info data with multi-branch packaging workflow

Ben Finney ben at benfinney.id.au
Fri Sep 12 07:09:55 BST 2008


Howdy all,

I'm experimenting with the 'version-info' command, and I'm very glad
this has been implemented. However, I'm a little confused on the
implications for workflow.

Currently I have a hypothetical project, 'foo', using the Python
language, which has the following workflow:

* cd ~/src/foo.devel/
* hack hack hack
* make test # runs the unit test suite
* make dist upload # makes Python distribution and uploads to PyPI
* bzr commit

* cd ~/src/foo.debian/
* bzr merge ../foo.devel/
* bzr-buildpackage --export-upstream ../foo.devel/
* lintian ../build-area/foo_1.2.3-7_source.changes
* dput ../build-area/foo_1.2.3-7_source.changes
* bzr commit

I would like to generate the file 'foo/version_info.py' by the
following make rule:

    foo/version_info.py:
            bzr version-info --format-python > $@


My questions are several.

How should I automatically trigger the generation of the
'foo/version_info.py' file? It will be used in many places throughout
the code base, including in 'setup.py', so it needs to be generated
ideally on every commit.

Should I add the generated 'foo/version_info.py' file to the VCS
branch? It's an auto-generated file, which argues "no"; but the
process of building the Debian package requires that the command 'bzr
export ../foo.devel/' must get the upstream source working tree, which
argues "yes".

How can I ensure that the generated 'foo/version_info.py' file is
*not* generated in a branch such as 'foo.debian/'? That branch should
use the "upstream" version-info output, not the info relating to the
Debian-packaging-specific branch.

-- 
 \     “To save the world requires faith and courage: faith in reason, |
  `\            and courage to proclaim what reason shows to be true.” |
_o__)                                                —Bertrand Russell |
Ben Finney




More information about the bazaar mailing list