lazr.smtptest wasn't packaged in Debian yet, so I thought it would be a good candidate for experimenting with one of the git-based workflows, from scratch. The ITP is bug #758670. I decided to use git-dpm; here are my impressions so far. For reference I started with https://wiki.debian.org/PackagingWithGit/GitDpm but ended up using the git-dpm(1) manpage more than the wiki page. I think it's helpful to read through both, but I noticed some slightly different recommendations, especially when creating the initial repository. I think the manpage recommends creating the pristine-tar branch but the wiki omits that step. I have no opinion on whether it's good or bad, but I followed the manpage and created the pristine-tar branch. I needed to create the initial packaging, and I needed to patch upstream[1]. The workflows described in the manpage seemed easy enough to follow. As described in the d/README.source file, I ended up using upstream-lazr.smtptest as the upstream branch, added a pristine-tar branch, and used lazr.smtptest as the packaging branch (i.e. the one with the debian/ directory). When just mucking about in debian/ I was pretty much able to use normal git commands, and to build the package I just used `debuild -S` without trouble[2]. It was easy to tag the release using `git-dpm tag` and even to move the tag once with --refresh. All in all, it was a pleasant experience, but there were a few hiccups, as described following. * The egg-info directory is a PITA. The upstream tarball has a lazr.smtptest.egg-info directory. debuild -S blows this away, and then git thinks I want to delete it. It doesn't get staged, so it's easy to `git checkout -- lazr.smtptest.egg-info`[3], but it gets annoying *very* quickly after just a few debuilds. I'm not sure what the best way to handle this is, if there is one. * debian/patches/* get named automatically `git-dpm checkout-patched` creates a temporary patch branch. I had to patch the setup.py, so I just edited it as normal. Note though that you *must* commit this file while on the patch branch or it doesn't get quilt-ified, but it will still show up as modified on your packaging branch if you switch to it. Oh, and the first line of your commit message gets turned into patch name. I like that it handles quilt-ifying the patch automatically when you `git-dpm update-patches` but watch out with your commit messages or you may be left with a patch file that has an odd name. I didn't try to change that and see if git-dpm could still grok the patch. * You have to switch branches to build the package. I'm used to svn-bp's --svn-ignore-new feature where you can just make the change and build the package right there. This doesn't work in git-dpm because the temporary patched-lazr.smtptest branch does not contain a debian/ directory. This makes the workflow for developing a patch less convenient because you have to switch back and forth between branches in order to build and test your patch. * Switching branches makes my editor unhappy. Why is this a PITA? Because Emacs will notice that a file you're visiting in a buffer is changed and will prompt you reload it. I guess because checkout-patched deletes the debian directory and update-patches restores it, it makes Emacs unhappy. I suppose you also have to be careful not to write a buffer to the debian/ directory when in the patched-<pkg> branch. * Where to push the repo? I'm not sure that we have a definitive path on git.debian.org for team maintained packages under git, but there is a python-modules directory containing a few packages. So I pushed my branches to git+ssh://git.debian.org/git/python-modules/packages/lazr.smtptest.git It takes a bit of work to create this directory initially, but I found that gbp has a nice command you can corrupt <wink> into doing the right thing for you, e.g.: $ gbp create-remote-repo --remote-url-pattern "ssh://git.debian.org/git/python-modules/packages/%(pkg)s.git" --debian-branch lazr.smtptest The --remote-url-pattern option is needed to override the default collab-maint directory. The --debian-branch options is required for some reason. I'm not sure why it needs a branch here since it creates an empty repository, but it failed without it. After running this command, I set up a remote and pushed all three branches (the upstream, pristine-tar, and packaging branches), along with the tags, and everything seemed happy. Oddly, I don't see the repo here: http://anonscm.debian.org/cgit/ but I have no idea why. If this isn't a good location, let's decide on one and use it consistently. I'd rather it be something team oriented, not collab-maint. My choice seemed good enough for the Vcs-* headers for now, but I'm happy to move it to a better place if there is one. Anyway, I think that's it for now. Feel free to muck about in this package, but please do let me know if you want to push any permanent changes. Tomorrow I'll probably try to do a new upstream release to fix the typo in the setup.py so I'll do a new package version and see how well that process works. Cheers, -Barry [1] Despite the fact that I had done an upstream release not minutes before. ;) [2] I like building only the source package at this step, and then iterating with sbuild, pbuilder, and adt-run to ensure that everything builds, lintians, and passes DEP-8. [3] Man, how I hate that spelling for $vcs revert. :/
Attachment:
signature.asc
Description: PGP signature