[Pkg-crosswire-devel] Plan for Summer =)

[Dmitrijs Ledkovs]

Hello =)

Launchpad is getting "building packages from bzr branches" =) the UI
has landed but the feature hasn't been enabled yet.

In the light of this features and features landed in dpkg I want to
propose following structural changes to our packaging branches:

=== PPA supports ===

Continue publishing binaries, but no more updates to hardy, intrepid, jaunty.

This would narrow down the support to karmic, lucid & maverick.

=== 3.0 (quilt) by default ===

For the official repository (debian sid, ubuntu archive) use 3.0 quilt
by default. And use 1.0 for the ppa's until all of them support 3.0
(quilt) (karmic end of live April 2011)

(this means that we parse package version at clean target and write
debian/source/format based on that)

=== Rebase branches on top of upstream imports ===

It will be easier to provide daily builds from upstream $vcs if our
branches are rebased ontop of upstream branches

Such that upstream is branched off at a tag, tarball in imported, and
debian packaging is done on top

----x--------x---------> svn-trunk
     \        \
      x--------x-------> upstream (pristine-tar)
       \        \
        x---x--x-x-x-x-> debian

this will result:

1) full history of project (downside big initial clone, upside
possible to checkout upstream revisions)
2) pristine tarball delta is stored (possible to generate all upstream tarballs)
3) can cherry pick commits from trunk & merge back
4) can merge svn-trunk to build daily builds

I would like to push sword patches upstream. And with sword i would
help to have dfsg branch between svn-trunk & pristine-tar branch. In
dfsg branch we would only commit deletes of everything we don't like
=)

With patches there are two things we can do:

1) commit them to the tree & maintain a static patch
2) commit each patch to separate branch (pipe see bzr-pipeline plugin)
and export all patches from pipes into debian/patches (google
bzr-pipeline)
3) just have static patches as we have now

The easiest is to push all patches upstream =) and after that is to
keep patch handling in bzr as we did now. (although I have switched to
using bzr to handle patch rebase)


=== Why? ===

Official packaging branches eg lp:debian/package & lp:ubuntu/package
are structured like this, and it will be easy to do daily builds from
such packaging branch: simply branch trunk of the project and merge
debian packaging branch for a daily build.


= Second big thing =

Libsword packaging. dh provides everything that cdbs can do for us,
and dh has more features & gains features more quickly than cdbs. Also
I'm not confident in cdbs architecture, too much dependencies, and
order of declarations in cdbs is significant. It is a neat idea, but
imho cdbs grew into a large beast, which slows down the build process
& depends on debhelper anyways.

So I'm proposing to start using dh tiny style for packaging. I'm using
it in xiphos & I've prepared sword port. While I was at porting sword
I did a few other changes as well to reduce size of get-orig tarball
and manpage targets.

the merge proposal is here

https://code.edge.launchpad.net/~pkgcrosswire/libsword/dh-style/+merge/26079

if there are no objections I'd like to merge that.

What do you think?