bzr for packaging
martin.pitt at ubuntu.com
Fri Mar 9 07:55:43 GMT 2007
Matt Zimmerman [2007-03-08 16:41 -0800]:
> Martin and I are interested in feedback about bzr-builddeb, similar tools,
> and any other practices around using bzr for packaging.
> What are you doing? What works well? What is painful?
== keeping source packages in bzr ==
I found having packages in bzr is a great aid for packages which see
heavy development from my side (e. g. apport, postgresql-common,
restricted-manager) for the following reasons:
* Collaboration - merging from each other works really well, painful
* Community testing - "You test, report errors, I fix/commit/push,
you pull and test again" works just wonderful as well.
* Developing packages while traveling.
* Low overhead and high yield for packages which have lots of
changes relative to the number of uploads (like hal).
On the other hand, the painful things are:
* Lots of overhead if all you want to do is a single quick fix to a
package, since we do not have the same abstract tool support as
apt-get source provides (yay hct :) ).
* Easy to get out of sync between the archive and the bzr branch
(transitional mass uploads, forgot to check for bzr branch, etc.)
* Pushing and pulling from LP still takes quite long. I guess
deploying smart server will help tremendously?
== common practice that I found to work well ==
* Keeping bzr and Debian changelog in sync. I usually write the Debian
one and use  to automatically generate a bzr one. However, this
could become a more official and better integrated tool (plugin
instead of a shell wrapper).
* Keeping the changelog release as 'UNRELEASED' while committing
changes. This makes it easy to see for other people that they must
not start a new package revision. As a very last step before
uploading, s/UNRELEASED/feisty/ and
bzr commit -m 'release as 1.2-3 to feisty'
so that it is easy to retrieve older package versions just by
looking at bzr log.
== tools ==
* http://codebrowse.launchpad.net: REALLY REALLY useful for discussing
changes with other devs. Kudos to whoever set this up. However, why
is this such a secret? It should be prominently linked from
* I never used bzr-buildpackage and similar so far. debuild -i -I.bzr
keeps source packages clean, and as long as we do not have real
upstream branches, I do not see the benefit of such a thing. But
you never miss what you don't know, so maybe there are some
non-obvious goodies in it.
(read it as 'bzr debian commit' and blame my Huffman-coding-like
script and alias names)
Martin Pitt http://www.piware.de
Ubuntu Developer http://www.ubuntu.com
Debian Developer http://www.debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Digital signature
Url : https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20070309/43ae5ccb/attachment.pgp
More information about the ubuntu-devel