UDD health check?

[Barry Warsaw]

On Jul 13, 2010, at 03:26 PM, Elliot Murphy wrote:

>On Tue, Jul 13, 2010 at 2:47 PM, Barry Warsaw <barry at canonical.com>
>wrote:
>> As an example: I'm trying to get two of my spinoff Python packages
>> into Ubuntu, via Debian.  They are packaged in neither atm.  I'm the
>> upstream maintainer and the projects are hosted on Launchpad, so it
>> starts off easy enough by creating a branch of trunk, and loomifying
>> the work branch.  I create a thread for Debian development, use
>> stdeb to create the initial debian/ directory, then create a thread
>> for Ubuntu.  This latter is what I build the source package for the
>> PPA from.
>>
>> This is a nice arrangement because as I modify the trunk (and make
>> non-Debuntu releases), I can pull the trunk into the bottom thread,
>> up-thread --auto and be ready to spin a new PPA (yes, I know, I
>> haven't yet started to use build-from-branch).
>>
>> The debian thread is less useful though, because what the DPMT wants
>> is *just* the debian/ directory in their svn, and that workflow is
>> completely different.  The last update I made, I resorted to
>> rsync'ing the debian directory to an svn checkout from alioth.  Not
>> fun.
>
>This is fascinating to me. I still can't quite grok the reason for
>using bzr at all in this case, and I'd be interested in understanding
>what it gives you. I don't understand how you are able to work from a
>bzr branch when packages want orig tarballs. I have been working
>exclusively from tarballs that I upload to launchpad/pypi, then
>copy/paste/edit a debian/ directory with a watch file, build the
>initial source package, and svn-inject it. Then I sync to ubuntu and
>would use UDD if I needed to do an Ubuntu specific patch only after
>the importer set up all the branches.

I don't claim any brilliance or efficiency in the way I have things set up,
but it seems to have some advantages for the way I work.

The first thing is that everything I do lives under subdirectories in my
~/projects directory.  If a package is maintained under bzr subdirectories
under that will be shared repos.  So for example, all my work on flufl.enum,
be it as the upstream maintainer, packager, whatever, will live under
~/projects/flufl.enum (well, tbh, I tend to throw all namespace package under
an umbrella shared lib, e.g. ~/projects/flufl/flufl.enum will be the trunk of
that package's upstream code).

I like to use stdeb to create the initial debian directory for Python
packages, because it understands distutils-isms and will initialize things
like the control file from setup.py.  So `python setup.py debianize` makes it
really easy to get a functional, nearly complete packaging layout.  Yes,
you've got the source and no tarball, but still, you're pretty close to a
useable package right at that point.  stdeb has a few bugs and annoyances, so
you still have to manually edit things, but you're darn close already.

I also have a debian/watch file pointing to my Cheeseshop tarball (automating
this is something I want to add to stdeb).  Almost always the next thing I
want to do is throw the package in my PPA, so it's pretty easy at that point
to `bzr bd -S`, and dput the results to my PPA.  The fact that the source,
while unnecessary, is still there, can be helpful if I need to consult say the
NEWS file or other changes for updating debian/changelog.  I do sometimes want
to just pdebuild (`bzr bd`) a .deb right there and then.

Also, if I find that I need to make changes in the upstream source in order to
improve the packaging in my PPA, I've got everything I need right there (in
that case, a `python setup.py sdist` gives me a tarball that can substitute
for the watched upstream release).  Plus now I've got my dvcs tools available
to merge any of those relevant changes back into my trunk.  Having the debian/
directory living in a sourceful branch also gives me a little more comfort
than a lone debian/ directory just floating out there.  This is probably just
a crutch from years of wanting everything for a project under one roof.

This arrangement is also kind of nice when I push the branch and pull it from
another machine, which I do often.  Having everything living in a loom (now
that these can be pushed and pulled from LP without loss of fidelity) means I
can really keep everything together and just hop around, branch one thing and
get all my work back.

Where does your debian/ directory live in the dvcs cloud?  IOW, do you have a
separate unrelated branch that just includes debian/ and do you push that to
LP?  Or does that live only in Debian's svn once you've injected it (i.e. you
only make packaging changes to that directory).  Do you spin PPAs from that
same debian/ directory or do you make a branch of that to do the PPA changelog
dance?

The debian/ directory is certainly separate, but it's also related.  E.g. when
you branch an Ubuntu source package, e.g. `bzr branch lp:ubuntu/simplejson`
what do you get?  A sourceful layout with an embedded debian/ directory.  So
in that sense, my loom looks a lot like that.  Maybe this crutch becomes less
necessary when we have nested branches, or when I'm more familiar with
build-from-branch recipes.

Now lets talk about automatic loom to quilt patch generation. :)

-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
Url : https://lists.ubuntu.com/archives/ubuntu-distributed-devel/attachments/20100713/89eadbe1/attachment-0001.pgp