Packaging of plainbox-provider-checkbox

[Zygmunt Krynicki]

Hey

I'd like to announce that I've created a git-dpm managed repository
for packaging of the checkbox provider [1]. This is big news as it
will allow us to use one repository (with common history, where
possible, and cherry-picking otherwise) to manage releases of the
checkbox provider.

What does it mean?
1) It was a necessary experiment due to some git/bzr conversion tools
that made me otherwise stuck
2) We can abandon this and return to our recipe builds (as long as we
are still using bzr)
3) We can keep using it and manage releases using this packaging
repository (and keep it in Debian in the collab-maint area, moving the
current packaging repository out of svn and into git-dpm managed git,
as recommended for all python modules)

So what does that mean technically?

With that in place, both releases are made from the upstream tarball
we publish on launchpad (so less errors are caught when we actually
try to release to Debian and notice something is wrong). The only
significant difference between both packages (for the PPA and for
Debian/Ubuntu) is related to three topics:

- The PPA supports precise so it handles some things differently. In
precise dh-python does not exist so we cannot rely on it. This is a
minor inconvenience in this case but it's a pain as hell for python3-*
packages.
- The PPA supports precise (do you sense the pattern here) so it
cannot use manage.py packaging (which depends on python3-debian) to
use provider meta-data units. This is obviously a problem as it
derails the effort to simplify packaging maintenance by keeping track
of dependencies in the provider and not in various packaging branches.
Here it's not a major problem because we just don't have any packaging
meta-data units in the checkbox provider yet.
- Due to us not really going through with the MIR process the provider
in Debian/Ubuntu has much weaker dependencies (we just cheat and put
everything in Suggests AFAIR). In our PPA those are actual
dependencies (Depends:). I retained this fact as I didn't want to
explore this mine field today. Properly addressing this issue would
require us to reliably track what we actually depend on, describe that
in a machine readable way and perhaps split the provider in some spots
as different customers want different subsets  and lastly, do the MIR
paperwork for anything that needs it.

I've asked Maciek to review the packaging system. Given his green
light I will go ahead and dput the package into the testing PPA. From
there it can be verified and copied to the public stable PPA for
everyone to consume.

[1] https://code.launchpad.net/plainbox-provider-checkbox

Thanks
ZK