On Tue, Jul 13, 2010 at 2:47 PM, Barry Warsaw <[email protected]> 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. -- Elliot Murphy | https://launchpad.net/~statik/ -- ubuntu-distributed-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
