Best way to use bzr for Ubuntu packaging?

[Torsten Bronger]

Hallöchen!

James Westby writes:

> Torsten Bronger wrote:
>
> [...]
>
>> Or, one repository with three branches for Hardy etc, and in each
>> a loom with upstream, patches, and debian.
>
> I think I prefer this one, though it does seem like repeated work.
> Perhaps the lower parts of the stack can be shared.

Actually we need loom threads with trichoptilosis.  ;-)

>> Probably I'm equally confused as confusing ... how would you do
>> it?
>
> [...] I'd be interested in your experiences so that we can learn
> what the advantages of the different methods are.

After a week in the health club with manuals for bzr-builddeb, loom,
and Ubuntu packaging on the elliptical trainer, I do now the
following:

I have no upstream thread.  Instead, I start the loom directly with
"karmic", the older distros following.  The reason for this ordering
is that I expect that new upstream versions need more adaption work
the older the distro is.  Besides, young distros have higher
priority for me.

(Actually, the first thread is called "ubuntu_current" because you
can't rename the first thread in loom yet.)

The upmost thread is Debian since I don't use it myself.

So why no "upstream" thread?  Actually with bzr-builddeb, I see no
reason for separating the thread with the debian/ directory from the
upstream.  Moreover, I think it is not feasible to contribute to the
upstream project by letting them merge my upstream thread.  I expect
this to work in too few cases.  If you want to participate in actual
development, do it in a separate branch.  And/or send patches.  This
is not elegant but functional.

This may be different if "merge-upstream" was loom-aware and knew
about separate "upstream--debian" threads.  But I think this would
violate the KISS principle heavily.  Just too many things that can
break ...

But there is yet another thing.  An upstream thread makes only sense
if you actually merge the upstream VCS into it, so that it has the
proper base.  But if I have tarballs, I prefer to only merge the
tarball because you can never be sure that the revision in the VCS
and the tarball really contain the same files.

So in an ideal world where everyone can merge Bazaar branches and
all release tarballs correspond to a revision, one could do it
slightly more elegant, but I think I can live with this solution
even for complex packaging.

Tschö,
Torsten.

-- 
Torsten Bronger, aquisgrana, europa vetus
                   Jabber ID: torsten.bronger at jabber.rwth-aachen.de
                                  or http://bronger-jmp.appspot.com